> 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

Date: Fri, 13 Feb 2004 23:11:52 -0500
X-Trace: news.povray.org 1076710053 80.145.157.36 (13 Feb 2004 17:07:33
-0500)

Could you please fix your system time and/or timezone?

    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 <402d4192@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

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

Would it necessarily do so? I don't see how it could be a problem for a 
parameter name to hide a parse-time variable name. The person writing 
the function could change the parameter name if the variable is needed, 
otherwise it just avoids situations like this one.


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

Shorter: end the name with an underscore: a_
A keyword won't end with an underscore, and variable names typically 
don't either, aside from it being recommended to use upper case letters 
in them. I don't see a reason for the parameters to conflict with 
parse-time variables, though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-618DF4.19175614022004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> Would it necessarily do so? I don't see how it could be a problem for a
> parameter name to hide a parse-time variable name.

You have to keep the difference between functions and macros in mind.  Just
imagine what would happen if you would be doing this, in particular if you
also consider #undef.  A mess is the result, and while you can perhaps clear
it up in the simple example below and define rules, those will quickly break
with a more complex example.  You really don't want it, because then which
scope applies were, in particular in macros that just generate functions
will no longer be clear.

    Thorsten

#macro minsert1()
 #undef a
 a
#end

#macro mfoo1(a)
 minsert1()
#end

#macro minsert2()
 a
#end

#macro mfoo2(a)
 minsert2()
#end

#declare fn1 = function(a) { mfoo1(10) }
#declare fn2 = function(a) { mfoo2(10) }
#declare fn3 = function(a) { minsert1() }
#declare fn4 = function(a) { minsert2() }

#macro m1(a)
 mfoo1(10)
#end

#macro m2(a)
 mfoo2(10)
#end

#macro m3(a)
 minsert1()
#end

#macro m4(a)
 minsert2()
#end

#debug str(fn1(1), 0, 0)
#debug " "
#debug str(fn2(1), 0, 0)
#debug " "
#debug str(fn3(1), 0, 0)
#debug " "
#debug str(fn4(1), 0, 0)
#debug "\n"

#debug str(m1(1), 0, 0)
#debug " "
#debug str(m2(1), 0, 0)
#debug " "
#debug str(m3(1), 0, 0)
#debug " "
#debug str(m4(1), 0, 0)
#debug "\n"

Post a reply to this message

> Could you please fix your system time and/or timezone?
Sorry. It's done now.

Florian

Post a reply to this message