POV-Ray : Newsgroups : povray.beta-test : Buglist 22 Apr 2002 (RC2) : Re: Buglist 22 Apr 2002 (RC2) Server Time
26 Sep 2024 17:44:35 EDT (-0400)
  Re: Buglist 22 Apr 2002 (RC2)  
From: Coridon Henshaw
Date: 5 May 2002 02:57:30
Message: <Xns92051E17F8CBDcsbhccse@204.213.191.226>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.