Chris Huff <chr### [at] maccom> wrote:

> In article <3a3f78dd@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> That's probably what I'll have to do.  It's not very extensible though.  
>> If someone wants to use their own parameterization, that isn't 
>> provided in the base code, they have to not only write the new macro, 
>> but give it an identifier and add it to the multiplexer macro.

> Just let one of the macros be a "user macro", with a specific, 
> documented name. That way, the user can write their own macro with this 
> name, which your code already knows to call if the control variable has 
> a certain value.


>> Hmm, can a macro be defined in terms of itself?  Ie, can you have 
>> something like:
>> 
>> #macro test_macro()
>>   test_macro()
>>   other stuff
>> #end

> That depends on what you mean by "defined in terms of itself". What you 
> wrote there is an infinitely recursive macro...once you call it, it will 
> call itself, call itself, call itself...ad infinitum. You need to use an 
> #if() block and a counter variable to tell it when to stop calling 
> itself. Then it will return through all the "other stuff" once for every 
> call.

What I meant was a macro that is redefined based upon it's previous state. 
Much like with variables:

a = a+1;

for example.  It takes the previous value of a and applies it to the new
expression.  Macros don't work like that, and as far as I know, very few
programming languages allow such constructs, so I'm not surprised that POV
doesn't either.

However, with the solution you posted in the other thread (how to evaluate a
function), it might not be necessary at all.  Most of my macros are the
calculation of single values, so can easily be functions.  There are only
one or two that are tricky, and those can be worked around in this fashion.

Geoff

Post a reply to this message