On Fri, 02 Mar 2001 16:29:36 -0500, Chris Huff wrote:
>I don't see the problem...

The problem is that #set just makes the syntax more complicated; see below.

>I wouldn't write code like that, unless I wanted a global version of 
>"Var"...the #set versions would look for a global variable named "Var" 
>or take a specific variable and modify it, no matter what it's name is.

FWIW, I wouldn't write code like that either, but in the context of an
include file it makes more sense.

>I still do not think a macro should be able to modify local variables 
>outside it unless they are passed in as a parameter or are simply at a 
>higher level (#local variables of the include file the macro is in, for 
>example. *Not* #local variables of macros that call the macro.). Of what 
>use is this behavior?

By the way, trying to modify local variables of the include file the macro
is in will not do what you think it will in all cases.  The local variables 
of that include file will go out of scope when it finishes parsing, which
is quite likely to be before the macro is invoked the first time.

In any case, include files and macros are the same thing internally.  
Include files are just bigger, in general.

The behavior is most useful when you're writing an include file or a macro
that needs to call certain other macros (possibly ones you didn't write) 
that change the values of global variables, and you don't want those changes
to affect anything the person who called your include file might have had
going on.  Suppose you're planning on building something on top of Colefax's
spline include file, perhaps a roller coaster construction set.  Suppose you 
plan to make it available for public use.  Further suppose that Colefax's 
spline include file uses global variables, since I haven't checked that it
does. :) Now, what happens when someone uses your roller coaster construction
set to make a roller coaster, then uses Colefax's splines to make, say, the
string of a balloon?  Do the globals get mixed together higgledy-piggledy?

To explain it more succinctly: the current behavior of #declare makes it
relatively transparent to turn .pov files into .inc files that can be used
from any .pov file, anytime, by making the "global" variable space not be
quite so global.  It's not that different than namespaces, really.  

If anything is a bug here, it's that macro invocations don't happen in the
context in which the macro was declared (called "closures" in CS-ese) but 
that's a can of worms nobody really wants to open (from a programming 
standpoint, that is - they'd be very useful from a scripting standpoint.)

>It just doesn't seem like a good idea for "#declare SomeVar = ..." to 
>behave differently depending on whether SomeVar already exists and 
>whether it is local.

Only on whether it already exists, not on whether it is local.  At any rate,
it's not something we can argue about: it's documented that way, it was
deliberately written to work that way, and that way it will stay.

>> It doesn't seem less confusing to me.  If you implement it, I forsee lots 
>> of
>> #ifdef (foo)
>>   #set foo = SomeComplicatedMacro();
>> #else
>>   #declare foo = SomeComplicatedMacro();
>> #end
>
>Why? That code would modify foo if it exists already, and otherwise 
>create a global variable named foo. What's confusing about that?

What's bad (not necessarily confusing) about that is that it'd have to crop 
up in lots of code that used to work:

#declare foo=0;
#while (foo < 100)
  #declare bar=Something(foo);
  DoSomething(foo,bar);
  #declare foo=foo+1;
#end

This would become a parse error in your version, because #declare would
find a defined identifier on the LHS the second time through the loop.
Making working scenes break is not generally considered A Good Thing.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message