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