John VanSickle <evi### [at] hotmailcom> wrote in news:3CD46365.433CEFA3
@hotmail.com:

>> Parsing fails on line 248 of shapes.inc when the Spheroid macro
>> attempts to use 'Center' as a parameter name.
 
> A consistent naming scheme will alleviate this problem.
> 
> For instance, I prefix vector names with a v, scalars with s,
> index variables with i, and so on.

This is what I'd call putting the cart before the horse.

Given that shapes.inc and the other #macro-laden #includes are a standard 
part of the distribution, I tend to think it'd make far more sense for them 
to use a consistant naming scheme to stay out of the *users* hair rather 
than for the user to go through all kinds of contortions to stay out of the 
#include's hair.

I mean, you wouldn't like the idea of prefixing every name in a C program 
with an underscore (etc) so it wouldn't collide with names used by the C 
RTL, would you?  Of course not.  That's why the component names used by C 
RTL are prefixed with underscores: so the user gets virtually the rest of 
the non-defined namespace to himself/herself.

Post a reply to this message

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

> It isn't a new limitation in 3.5 also you seem to give that impression.

Try this on 3.1:

#macro Center(Obj)
object {Obj}
#end
#include "shapes.inc"
#declare X = sphere {0,1}
Center (X)

It won't choke.  Now try it on 3.5.  Now try to find anything in the 
documentation that says this code is no longer valid under 3.5.

(Yes, I know /why/ it won't choke 3.1...  The reason why it won't choke 3.1 
is irrelevant; the fact that it *does* choke 3.5 is the problem.)

> Having the same name twice in the same namespace simply cannot work. 

Please tell that to the RC3 binary.  It copes just fine with #declared/
#localed names that match macro parameters:

#local X = function(x,y,z) {x+y+z}
#macro A(X) #end

Given that there's no valid reason to use the output of a macro to 
determine the name of another macro's parameters, not performing macro 
expansion during this portion of parsing seems reasonable for consistancy's 
sake alone.  For instance, why should the code above work when #macro X() 
#end #macro A(X) #end doesn't?

> the documentation explains the namespace rules. 

In this specific case, telling the user that he/she can't do #macro A() 
#macro B(A, D) is rather pointless when the user doesn't know that #macro B
(A, D) exists in the first place.  The point is that the standard includes 
are consuming huge swaths of the namespace without any real documentation  
or regard for what they might be stepping all over.  Finding safe names was 
not a matter of luck with 3.1; it is very much a matter of luck with 3.5 as 
soon as one #includes anything.  I don't think this change is particularly 
rational or user friendly.

Again, if the parser cannot practically be fixed at this stage, could the 
standard includes at least be modified so their macro parameter names are 
all lower case (like all other Pov keywords), mangled to reduce the chances 
of collisions with user macros, or added to the reserved keywords list in 
docs section 6.1.1?

Post a reply to this message

In article <Xns### [at] 204213191226> , che### [at] sympaticoca
(Coridon Henshaw) wrote:

>> Having the same name twice in the same namespace simply cannot work.
>
> Please tell that to the RC3 binary.  It copes just fine with #declared/
> #localed names that match macro parameters:
>
> #local X = function(x,y,z) {x+y+z}
> #macro A(X) #end

But that is a completely different case!  X is known to be a variable in both
cases and the variable namespace is well-defined.

> Given that there's no valid reason to use the output of a macro to
> determine the name of another macro's parameters,

You would be surprised what one can do (also the above can't be done) inside
macro parameter lists...

> not performing macro
> expansion during this portion of parsing seems reasonable for consistancy's
> sake alone.  For instance, why should the code above work when #macro X()
> #end #macro A(X) #end doesn't?

Because macros are in a completely different namespace.  In particular are
#macros behaving like macros and not functions (see <http://www.povray.org/
working-docs/id000153.html#6_2_8_3>) here.

As you know, #locals have a scope that is limited to files or the current
block while #macros are in a global namespace not really shareable with
#declares.  As POV-Ray identifiers are typeless there is significantly more
ambiguity when parsing such constructs.

As for the actual problem, by disallowing #declares (and anything that
implicitly declares an identifier) in parameter lists of #macro definitions
one can allow #macro identifiers as parameter names.  Nevertheless, this might
break some old scenes...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Coridon Henshaw wrote:
> 
> John VanSickle <evi### [at] hotmailcom> wrote in news:3CD46365.433CEFA3
> @hotmail.com:
> 
> >> Parsing fails on line 248 of shapes.inc when the Spheroid macro
> >> attempts to use 'Center' as a parameter name.
> 
> > A consistent naming scheme will alleviate this problem.
> >
> > For instance, I prefix vector names with a v, scalars with s,
> > index variables with i, and so on.
> 
> This is what I'd call putting the cart before the horse.
> 
> Given that shapes.inc and the other #macro-laden #includes are a
> standard part of the distribution, I tend to think it'd make far more
> sense for them to use a consistant naming scheme to stay out of the
> *users* hair rather than for the user to go through all kinds of
> contortions to stay out of the #include's hair.
> 
> I mean, you wouldn't like the idea of prefixing every name in a C
> program with an underscore (etc) so it wouldn't collide with names
> used by the C RTL, would you?  Of course not.  That's why the
> component names used by C RTL are prefixed with underscores: so the
> user gets virtually the rest of the non-defined namespace to
> himself/herself.

But I also use a consistent naming convention to avoid trampling
my own variables as well.

Regards,
John
-- 
Rusty is rendering!

Post a reply to this message