POV-Ray : Newsgroups : povray.general : Problem with name space for user-defined functions : Re: Problem with name space for user-defined functions Server Time
19 Apr 2024 02:28:39 EDT (-0400)
  Re: Problem with name space for user-defined functions  
From: Thorsten Froehlich
Date: 4 Apr 2018 08:00:00
Message: <web.5ac4bd87f0f198f8f773ca290@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> >
> > #macro P()
> >     #local B = 0;
> > #end
> >
> > #macro Q()
> >     #local B = function { 0 };
> >     P()
> > #end
> >
> > Q()
> >
> > // Error message in version 3.7.0.msvc10.win64 and in
> > // version 3.8.0-alpha.9322209+av499.msvc14.win64 for the code above:
> > // "Parse Error: Redeclaring functions is not allowed - undef# the function
> > first!"
>
> Same error message in v3.7.1 beta 9 (on Win 7)
>
> But that construct is essentially the same as this (and the original #macro P()
> can be commented-out, with no change):
>
> #macro Q()
> #local B = function { 0 };
> #local B = 0;
> #end
> Q()
>
> This throws the same error. So it appears that B can't be re-#local'ed there,
> even though the 'new' B is not actually a new function.
>
> However, this throws NO error...
> #macro Q()
>     #local B = function { 0 };
> #end
> #local B = 0; // or #declare
> Q()
>
> Strange. Although, in this case, the 'first' #local B to be 'processed' is
>    #local B = 0;
> which is NOT a function. So when B is then #local'ed again inside macro Q()--
> only when Q() is INVOKED, apparently-- all is well.
>
> BTW, there's no error at all when Q() is not actually invoked. That's
> interesting; I thought your original code error might still appear, when POV-Ray
> initially 'reads' #macro Q() in the SDL.
>
> >
> > - and this:
> >
> > #macro M()...
> [snip]
>
> No error in my version either.

The behavior is logical because of the scoping rules that local implies. These
rules apply at the time of invocation, not the order in which a macro is
defined. It is also perfectly legal to redefine a local variable to be a
function.

Internally the logic is very specific: The code prevents you to overwrite a
function unintentionally. The rationale is that you should always be aware of
what you are doing with functions, which do not perfectly it into the POV-Ray
pseudo-variable system.

The behavior is also necessary because internally functions, unlike variables,
exist beyond the time parsing finishes.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.