Warp wrote:
>>It should not crash of course but your code isn't valid syntax, it can't 
>>work.
> 
>   I have to admit that I'm not sure why it's not valid syntax... (Perhaps
> you should have specified why? :) )

Are you serious?

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

#local F1= fn_p;

#declare fn_crash = function(x,y,z) { F1(x,y,z) }


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

Christoph Hormann <chr### [at] gmxde> wrote:
> >   I have to admit that I'm not sure why it's not valid syntax... (Perhaps
> > you should have specified why? :) )

> Are you serious?

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

> #local F1= fn_p;

> #declare fn_crash = function(x,y,z) { F1(x,y,z) }

  Sorry, but I still don't see it. Perhaps I'm unusually dumb today.

  The only thing which I can think of is that you can't create an
identifier and directly assign a function to it (ie. #local F1 = fn_p;),
but if that's so, it's illogical and works differently from any other
identifier type.

  (Compare it to this: You have a #local A = sphere { 0,1 }; and
then you can do #local B = A; and you don't have to do it like
#local B = object { A };)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
>   Sorry, but I still don't see it. Perhaps I'm unusually dumb today.
> 
>   The only thing which I can think of is that you can't create an
> identifier and directly assign a function to it (ie. #local F1 = fn_p;),
> but if that's so, it's illogical and works differently from any other
> identifier type.
> 
>   (Compare it to this: You have a #local A = sphere { 0,1 }; and
> then you can do #local B = A; and you don't have to do it like
> #local B = object { A };)

This is to make it easy to distinguish between function calls and 
function declarations:

#local X=function (Y) { Y }

#local Y=0;

#local Val1=X(0);
#local Val2=X(Y);

#undef Y

#local Fn1=function (Y) { X(Y) }


I assume it would be possible to allow the '#local B = A' form for 
functions as well (although it might be difficult to implement) but 
possibilities for obfuscation are already sufficient IMO.

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

In article <3faff7a7@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> It should not crash of course but your code isn't valid syntax, it can't
>> work.
>
>   I have to admit that I'm not sure why it's not valid syntax... (Perhaps
> you should have specified why? :) )

A local function is returned by value.  However, you cannot return a
function by value, you can only return a function result by value.  So after
the parser notices that this is a function assignment, it attempts to assign
it, but does of course fail because by the time it can notice, the macro has
already been left and the function no longer exists.  The reason is that
functions are not copied like other identifiers, but referenced (even if it
would be copied, the problem would remain to decide whether to copy or
evaluate).  However, the parser cannot decide what to do prior to leaving
the macro either.  Hence, this syntax cannot legal.

That said, I have no good idea how to tell the parser to detect such a case
yet (without some brain-dead ugly hack, of course).  Most likely this
problem will persist until POV-Ray 4.0.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3fafe73e@news.povray.org> , "JC (Exether)" <no### [at] spamfr> wrote:

> #macro F_Plane ()
>    #local fn_p=function (x,y,z) { y };
>    fn_p
> //  function (x,y,z) { fn_p (x,y,z) }
> #end

This isn't legal syntax and POV-Ray cannot currently detect this properly.

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

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> This isn't legal syntax and POV-Ray cannot currently detect this properly.

Isn't there a possibility to prevent the crash?

> 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:

DECLARATION:
     #declare IDENTIFIER = RVALUE |
     #local IDENTIFIER = RVALUE
RVALUE:
     FLOAT; | VECTOR; | COLOR; | STRING | OBJECT | TEXTURE |
     PIGMENT | NORMAL | FINISH | INTERIOR | MEDIA | DENSITY |
     COLOR_MAP | PIGMENT_MAP | SLOPE_MAP | NORMAL_MAP |
     DENSITY_MAP | CAMERA | LIGHT_SOURCE | FOG | RAINBOW |
     SKY_SPHERE | TRANSFORM


Function documentation only lists the full declarations:

FUNCTION_IDENTIFIER:
     #local FUNCTION_IDENTIFIER = function { FLOAT }               |
     #declare FUNCTION_IDENTIFIER = function { FLOAT }             |
     #local FUNCTION_IDENTIFIER = function(IDENT_LIST) { FLOAT }   |
     #declare FUNCTION_IDENTIFIER = function(IDENT_LIST) { FLOAT } |
     #local FUNCTION_IDENTIFIER = function{SPECIAL_FLOAT_FUNCTION} |
     #local VECTOR_IDENTIFIER = function{SPECIAL_VECTOR_FUNCTION}  |
     #local COLOR_IDENTIFIER = function { SPECIAL_COLOR_FUNCTION } |


Calls to user defined functions are missing in the 'Float Expressions' 
as well.

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

In article <edn### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

>> This isn't legal syntax and POV-Ray cannot currently detect this properly.
>
> 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

The reason I suspect this might work is because it practically completes the
copy assignment prior to leaving the macro.  Thus, the parser is no longer
waiting to be able to figure out if the above is a copy or a evaluation.

>> 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.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

In article <4vo### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> 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.

As, I see, and agree.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 10 Nov 2003 20:30:57 +0100 JC (Exether) wrote:

>I tried to post this message three times in P.bugreports and it didn't 
>work, sorry if I'm multiposting.

  JC, thank you for reporting it here.  Please read "bug reporting" in
the povray.announce.frequently-asked-questions group.  I would have
directed you to that article upon receiving your first report but you
gave no valid e-mail address.

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message