Thorsten Froehlich wrote:
>>Isn't there a possibility to prevent the crash?
> 
> 
> Not without making macros aware of what they are returning.
> 
> Actually, thinking about this again, I think the following should work as
> well (sorry, I cannot test it right now):
> 
> #macro F_Plane ()
>     #local fn_p=function (x,y,z) { y };
>     fn_p;
> #end

It works.

>>>To do what you want, use #declare instead of #local like this:
>>>
>>>#macro F_Plane ()
>>>   #undef fn_p
>>>   #declare fn_p=function (x,y,z) { y };
>>>   fn_p
>>>#end
>>
>>Note this is an undocumented feature.  In fact function declarations are
>>not listed in the #declare documentation at all:
> 
> 
> True.  And it shouldn't be documented for now as I am not sure if it should
> be allowed or not.  Macros should only return "complete" unambiguous
> statements.  The workaround only works because a #declared function isn't
> destroyed after leaving the macro like a #local function.  The parser cannot
> detect either case, but as it doesn't destroy the #declared function when
> leaving the macro, the code works as expected.  I suppose even doing
>     #local F1= F_Plane()(1,2,3);
> would work in this case.  I really don't want to endorse this syntax, and I
> won't promise future versions of POV-Ray will still allow it.  So if my
> suggestion with the semicolon does work, that would be the recommended way
> of handling this.

I was not referring to macros at all, the fact that

#declare fn_p=function (x,y,z) { y };

#declare fn_q=fn_p;

does work is not documented, the fn_p declaration only in the function 
chapter, not in the #declare chapter.  This should be changed IMO, as 
well as adding user defined function evaluations to possible float 
expressions.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message