POV 3.5 b 10.icl on PII 233 128 MB with NT 4 Sp 6

Following code returns parse error about recursion but there is no recursion

//<SDL>
  #macro F()
    #local E=function(c){c};
    function(k,l){select(E(k+l),0,1)}
  #end
  #declare E=F();
//</SDL>

Output:

function(k,l){select(E(k+l),0,1)} <----ERROR
Parse Error: Recursive function calls are not allowed!

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> Following code returns parse error about recursion but there is no recursion
>
> //<SDL>
>   #macro F()
>     #local E=function(c){c};
>     function(k,l){select(E(k+l),0,1)}
>   #end
>   #declare E=F();
> //</SDL>
>
> Output:
>
> function(k,l){select(E(k+l),0,1)} <----ERROR
> Parse Error: Recursive function calls are not allowed!

Well, while it is not obvious, there is a recursion here:

The function E exists "twice", once as a local function and once as a global
function.  However, you insert the local function E into the global function
E via a macro.  As the parser resolves the function E after the declare, it
notices that you call a function with the same name.  As the macro merely
substituted the the F() with function(k,l){select(E(k+l),0,1)} it can no
longer know that the name E isn't meant to be the global E but the local E.
On the other hand, if you use a different name, it no longer has a problem
with it because there is no ambiguity.

Technically there is no ambiguity when using a local and global function E,
but the parser protects you from creating a recursion in either case.  I
don't think the recursive function rule for functions with the same name can
be removed because it would create ambiguities should recursive functions be
allowed in later versions.  Then the parser would no longer know for sure
whether E is of local or global scope when it finds it inside a function...


    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 Tue, 22 Jan 2002 16:03:39 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> The function E exists "twice", once as a local function and once as a global
> function.

Yes, I noticed this. And it is not very big problem for me to avoid such
situations but I prefer to report it and get official answer to create some kind
of background for future newbies. This case appeared for me when I translated
code from MegaPOV to 3.5 so if anybody maintains tutorial of such translation...

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

>> The function E exists "twice", once as a local function and once as a global
>> function.
>
> Yes, I noticed this. And it is not very big problem for me to avoid such
> situations but I prefer to report it and get official answer to create some
> kind of background for future newbies. This case appeared for me when I
> translated code from MegaPOV to 3.5 so if anybody maintains tutorial of such
> translation...

The actual root of all these restrictions is that different nature of
functions.  While they are declared like anything else they have the unique
ability to exist after parsing.  This basically forces them into a separate
namespace, which, while parsing is the same as that of the parser, but when
actually "compiling" a function only the namespace of the functions is
available as they "sit on top of the parser" (the code really does, too!)

This creates other funny situations:

#declare foo=function{x}
#declare foo2=function{foo(x,0,1)}
#undef foo
#declare foo=function{x}

Now, what does this do?  Well, there are actually two functions "foo" now,
however, the name of the first function foo has been forgotten by the parser
while the function VM still remembers the actual function, but without a
name (internally functions are tracked via unique numbers).

However, should someone later to a "#undef foo2", the original foo will also
cease existing.  This not only reduces memory consumption, but it also helps
to stay in the limit of 65535 unique functions per scene.

The example above and other very strange cases were the reason why
originally redeclaring functions wasn't allowed in 3.5.  There is an
enormous overhead while parsing but only then!) function to make sure there
are no inconsistencies and there are no orphan functions or functions that
get accidentally replaced by redeclaring them (I think redeclaring would
replace the previous function in MegaPOV when rendering).

    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 Tue, 22 Jan 2002 17:08:18 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> #declare foo=function{x}
> #declare foo2=function{foo(x,0,1)}
> #undef foo
> #declare foo=function{x}
...
> (internally functions are tracked via unique numbers).

Thank You for explanation. And little additional question: is below script
supposed in this design to be also treated as recursion ?

#macro F()
  function(k,l){
    #local E=function(c){c};
    select(E(k+l)
    #undef E
    ,0,1)
  }
#end
#declare E=F();

ABX

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c4d8e7f@news.povray.org...

<snip>

Interesting....

Testing....

#declare foo = function(x){x*10}
#declare bar = function(x){foo(x)}
#undef foo
#declare foo = function(x){x}

#local X = bar(1);
#local Y = foo(1);
#debug concat("X = ", str(X,0,0), "\n")
#debug concat("Y = ", str(Y,0,0), "\n")

Wow!

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> Thank You for explanation. And little additional question: is below script
> supposed in this design to be also treated as recursion ?
>
> #macro F()
>   function(k,l){
>     #local E=function(c){c};
>     select(E(k+l)
>     #undef E
>     ,0,1)
>   }
> #end
> #declare E=F();

Interesting question.  I would have to step through the source code and see
what actually happens when.  Also I haven't tried your script it might be
possible to trick the parser this way, but I am not sure...

    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 news:3c4d8e7f@news.povray.org Thorsten Froehlich wrote:

> The actual root of all these restrictions is that different nature of
> functions.

Could somebody please write a new introduction to "User-defined 
functions" (6.1.6) in a way that it is understandable for every user? 
There already have been several situations where the users expectations 
don't match with what actually happens in POV-Ray.
Can't write it myself as I barly understand what implications this all 
has.

Ingo

Post a reply to this message