The following code produces an unexpected error:

	#local A = 1;
	#local B = function (A) { A }

The error is:

	#local B = function (A <----ERROR

	Parse Error: Expected 'parameter identifier', float function
	'float identifier' found instead

Obviously, it is not allowed to use a function parameter with the same 
name as a previously declared identifier. The documentation does not 
mention this (Or I'm too blind to find it *g*).

Is there a reason for this behaviour?

I came across this error when trying something like this:

	#local A = 1;
	#include "math.inc"

Fails due to

	#declare atan2d = function (A, B) {degrees(atan2(A, B))}

in math.inc. With the current behaviour, I cannot use V, A, B, N, Mn, 
Mx, OMn and OMx as identifier names before including math.inc, because 
they are function parameters of functions declared in math.inc :(
If the current behaviour is really necessary (and I doubt it is), I 
suggest using names like mathinc_V, mathinc_A, etc. for this purpose 
(And yes, I know that this is an ugly way to do it *g*)...

Florian

Post a reply to this message

In article <402d339c@news.povray.org> , Florian Brucker <tor### [at] torfboldcom>
wrote:

> Is there a reason for this behaviour?

Well, a #declare is a parse time "macro" while a variable name in a function
is a render time definition.  Hence, the substitution of the "A" has to
happen prior to the parser evaluating any expression.

This is also why it is not easy to find in the documentation, because it of
course is not mentioned explicitly in the function description section (it
does not belong there at all), but in the description of directives.
However, even there the detailed differences between a "macro" and variable
are not really explained formally as they are a rather computer science
based topic that is very hard to simplify and requires a heavy CS background
to really comprehend.

    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 <402d339c@news.povray.org> , Florian Brucker <tor### [at] torfboldcom>
wrote:

> in math.inc. With the current behaviour, I cannot use V, A, B, N, Mn,
> Mx, OMn and OMx as identifier names before including math.inc, because
> they are function parameters of functions declared in math.inc :(
> If the current behaviour is really necessary (and I doubt it is),

It is absolutely necessary.  What you expect is functions to have a scope on
the same level as macros do.  This is not the case, and you don't want it to
be the case either (it is possible to construct cases where, if this would
be the case, it would badly break functions - i.e. when generating a
function with macros).

The solution is that the include files should not use generic names for
function variable names.  A good solution would be to use all lower case
variable names with a prefix, i.e. "math__a" (note the *two* underscore
chars, this makes sure this will never be a keyword) instead of "A" in
math.inc .  This would work because the documentation already suggests to
the user to never use all lower case names.

    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:
> [...]
> 
> The solution is that the include files should not use generic names for
> function variable names.  A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc .  This would work because the documentation already suggests to
> the user to never use all lower case names.

In all functions with only 3 or less parameters (like the atan2d()) you 
can simply use the standard x,y,z.

Christoph

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

Post a reply to this message

> The solution is that the include files should not use generic names for
> function variable names.  A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc .  This would work because the documentation already suggests to
> the user to never use all lower case names.

Sounds like a good idea. Thanks for your explanations!

Florian

Post a reply to this message

Thorsten Froehlich wrote:
> In article <402d339c@news.povray.org> , Florian Brucker <tor### [at] torfboldcom>
> wrote:
> 
> 
>>in math.inc. With the current behaviour, I cannot use V, A, B, N, Mn,
>>Mx, OMn and OMx as identifier names before including math.inc, because
>>they are function parameters of functions declared in math.inc :(
>>If the current behaviour is really necessary (and I doubt it is),
> 
> It is absolutely necessary.  What you expect is functions to have a scope on
> the same level as macros do.  This is not the case, and you don't want it to
> be the case either (it is possible to construct cases where, if this would
> be the case, it would badly break functions - i.e. when generating a
> function with macros).

Unless I misunderstand the question, he was asking why a named parameter 
(to a macro or a function) would be masked by a symbol from the global 
namespace.  It seems that your answer is that *macros* and *functions* 
should be scoped differently (which makes sense) but doesn't seem to 
apply to the scoping of the *parameters*.

Sorry to be dense, but I've re-read this about 5 times and it seems like 
you either didn't answer the question or I'm missing something.

So, can you please give an example?  When would it be important that the 
*named parameter* of a macro be altered by a global #declare?

Offhand it seems like a flaw in the parser handling of *parameters* of 
macros, albeit one that could be worked-around by applying a naming 
convention to the standard include files.

[BTW, I've written parsers/compilers/interpreters but haven't poked 
around in POV's source code.]

> The solution is that the include files should not use generic names for
> function variable names.  A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc .  This would work because the documentation already suggests to
> the user to never use all lower case names.

Incidentally, the documentation says for identifiers "the first 
character must be an alphabetic character" -- but underscores are 
apparently allowed (v3.5).

That said, I'd for my $.02 a double-underscore prefix would be shorter 
and easier to read:

    #declare atan2d = function (__a, __b) {degrees(atan2(__a, __b))}

However that would presume that the POV documentation state that POV 
won't use an underscore to start keywords, and the users should not use 
them except for parameters.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:402d3fac$1@news.povray.org...
> In article <402d339c@news.povray.org> , Florian Brucker
<tor### [at] torfboldcom>
> wrote:
<snip />

> However, even there the detailed differences between a "macro" and
variable
> are not really explained formally as they are a rather computer science
> based topic that is very hard to simplify and requires a heavy CS
background
> to really comprehend.

I'll take a shot at this one:

In the context of POV-ray, a #macro is just a convenient way to add more
code before it gets submitted to the rendering engine. For example, if you
call a #macro:

#macro Something(sweet)
  color rgb sweet
#end

Something (1)
...
It actually replaces the code before it renders the scene with:

color rgb 1
----

You just don't see that happen unless you generate files from POV-ray.

When you use a macro to make something like fur, it is actually making
thousands of thin little cylinders (or whatever depending upon how you
implement the fur) that you really couldn't hand-write unless you were a
masochist.

Variables are different -- when you are rendering, say, an isosurface, x, y,
and z in the call to the function change depending on the pixel POV-ray is
rendering at the time (not directly, though; it depends on where a straight
line from your eye intersects with the screen and object itself and the
pixel color depends on the light sources and material and... well,  it's
complicated, like Thorsten said).

Just think of #macros as a factory for writing code for you and variables as
something that gets evaluated for every pixel POV-Ray renders.

I know this is a simplification, but I think it gets the idea across.

Post a reply to this message

> Unless I misunderstand the question, he was asking why a named parameter 
> (to a macro or a function) would be masked by a symbol from the global 
> namespace.  It seems that your answer is that *macros* and *functions* 
> should be scoped differently (which makes sense) but doesn't seem to 
> apply to the scoping of the *parameters*.
> 
> Sorry to be dense, but I've re-read this about 5 times and it seems like 
> you either didn't answer the question or I'm missing something.
> 
> So, can you please give an example?  When would it be important that the 
> *named parameter* of a macro be altered by a global #declare?
> 
> Offhand it seems like a flaw in the parser handling of *parameters* of 
> macros, albeit one that could be worked-around by applying a naming 
> convention to the standard include files.
> 
> [BTW, I've written parsers/compilers/interpreters but haven't poked 
> around in POV's source code.]
You're right, this was my actual question. Although I wasn't that 
successful in explaining it like you :)

I just wondered why macro parameters are in the macro's local scope (and 
can therefore have the same name like higher scope identifiers) and why 
function parameters are in global scope.


Thanks for pointing that out
Florian

Post a reply to this message

In article <402d5b1a$1@news.povray.org> , Marvin Taylor 
<pov### [at] maltasoftcom>  wrote:

> Sorry to be dense, but I've re-read this about 5 times and it seems like
> you either didn't answer the question or I'm missing something.

You missed that we are talking about functions, not #macros.  They are very
different, and the section about functions in the documentation
(http://www.povray.org/documentation/view/140/) does a fairly complete job
of explaining the difference.

    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 <402e13f3@news.povray.org> , Florian Brucker <tor### [at] torfboldcom>
wrote:

> I just wondered why macro parameters are in the macro's local scope (and
> can therefore have the same name like higher scope identifiers) and why
> function parameters are in global scope.

Check section "6.1.6.2 Functions and Macros" and you may also want to check
section "6.2.8.3 Are POV-Ray Macros a Function or a Macro?" (keep in mind
that the later section was written for 3.1, not 3.5).

    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