I wrote a macro that caused the scene to bomb out because an include file had a
macro with a *local* variable with the same name as my macro.  This TOTALLY
DEFEATS THE PURPOSE of having local variables.

This scenario illstrates the problem:
______________________________________________________

#include "scope.inc"

global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
camera
{  angle 30
   location -10 * z
}

#macro A (Paint)
   texture
   {  pigment { rgb Paint }
      finish { specular 1 roughness 0.001 }
   }
#end

object
{  Ring (sphere { 0, 0.75 })
   A (<1,1,0>)
}
______________________________________________________

//scope.inc

#macro Ring (Atom)
   union
   {  #local A = 0; //<-- Parser bombs out here.
      #while (A < 6)
         object { Atom translate y rotate 60 * A * z }
         #local A = A + 1;
      #end
   }
#end
______________________________________________________


POV-Ray is a great program, but its scoping quirks have always irritated me to
no end.  I thought these quirks were confined to functions and global
identifiers, and I found workarounds.  I've seen the "I don't like the way this
works so it must be a bug" in the documentation and eaten it.  I've avoided
duplicate names for the sake of good coding practice, and that's probably why I
haven't run across the full extent of POV-Ray's scoping leakage before now.

But this "feature" means that one has to avoid the names of identifiers that, by
rights, one shouldn't have to know about.  Avoiding the names of public
identifiers is unavoidable and expected.  But having to avoid the names of
*internal* working variables of foreign subroutines (macros) is totally
unreasonable.  It means that any new include file is in danger of clashing with
WIPs.  It means that in the Object Collection, every little loop counter and
temporary variable must be prefixed, making for verbose, unwieldy,
hard-to-debug code.  If this is not a bug, then the spec needs to be changed.

I don't know of any other block-structured computer language that has these
problems.

This is such a major breach of structured programming principles that I'm sure
that someone else has complained about this, somewhere in the newsgroup
archives.  Just add me to the petition.  I trust that version 4.0 will get rid
*all* scope leakage--including the inability to redefine an identifier as a
different type.

Post a reply to this message

"Cousin Ricky" <ric### [at] yahoocom> wrote:

> This is such a major breach of structured programming principles that I'm sure
> that someone else has complained about this, somewhere in the newsgroup
> archives.  Just add me to the petition.  I trust that version 4.0 will get rid
> *all* scope leakage--including the inability to redefine an identifier as a
> different type.


While it can be a hassle, the documentation states that all macros are permanent
and global in scope.  If the variable A had shared a name with a #declared
variable, the local one would have behaved as expected (but there would be no
way to reference the global of the same name while the local identifier
exists).  As for the last part, of redefining an identifier as a different
type, Povray already permits that except for macros, because they are
permanent.  To do it for a macro, you must use the #undef directive.


Scope control is something I briefly wrote about for a tentative list of changes
for SDL in 4.0.  There is (as always) more than one way to address this.  What
would you recommend?  On my list I put down the introduction of namespaces and
some new directives for scope control:

<snip>
I wouldn't mind seeing new directives, such as #global for global variables
(instead of declare) and #const for properties that can be referenced but not
set (i.e. using #const with your camera{} block would allow macros to retrieve
the camera settings, but not change them).  #local should be truly local to its
block, and not freely accessible within a file unless it is defined outside of
other code.

#private might also be useful from properties that you want to keep hidden from
outside of the object, and maybe a #static storage class for some variables or
for preventing macros internal to another macro from being called externally.
</snip>

Even though pov 4 is probably a bit beyond the horizon, I have been slowly
building lists of things that have come up in discussion or things that I've
run into.  I'd appreciate it if you had any specific recommendations for
changes.

-Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
>
> While it can be a hassle, the documentation states that all macros are permanent
> and global in scope.

That shouldn't make a difference.  A local variable should override any and all
global identifiers within its scope.  That is the very purpose of local
variables: so different parts of a program need not be concerned about how the
other parts do their jobs.  I maintain that having to avoid name collisions
with the internal workings of external subprograms is totally unreasonable.
It's the cyber-equivalent of having your lawn mower fail because it uses the
same type of motor oil as your wife's car.

> If the variable A had shared a name with a #declared
> variable, the local one would have behaved as expected (but there would be no
> way to reference the global of the same name while the local identifier
> exists).

I should state that the main file and the include file were written by 2
different people--let's call them "Rick" and "Sam."

If Sam needed a global A from within a macro, then he (obviously) wouldn't
declare a local A.  But if he's writing a stand-alone include file, then how is
he supposed to know that Rick will declare a macro A?  And how is Rick supposed
to know that Sam has a local variable A in one of his (supposedly) black boxes?

>  As for the last part, of redefining an identifier as a different
> type, Povray already permits that except for macros, because they are
> permanent.  To do it for a macro, you must use the #undef directive.

Again, the permanence of macros (and functions) is not the issue.  When a local
identifier's scope is destroyed, the global identifier becomes accessible
again.

A macro parameter can have the same name as a macro.  If I name the macro Atom
instead of A, the scene runs fine.  Is a macro name less "global" or less
"permanent" in this case?

> Scope control is something I briefly wrote about for a tentative list of changes
> for SDL in 4.0.  There is (as always) more than one way to address this.  What
> would you recommend?  On my list I put down the introduction of namespaces and
> some new directives for scope control:
>
> <snip>
> I wouldn't mind seeing new directives, such as #global for global variables
> (instead of declare) and #const for properties that can be referenced but not
> set (i.e. using #const with your camera{} block would allow macros to retrieve
> the camera settings, but not change them).  #local should be truly local to its
> block, and not freely accessible within a file unless it is defined outside of
> other code.
>
> #private might also be useful from properties that you want to keep hidden from
> outside of the object, and maybe a #static storage class for some variables or
> for preventing macros internal to another macro from being called externally.
> </snip>

These are all good ideas.  But I would prioritize eliminating collisions between
local and global identifiers--something that should never be in the first place.

After that, I would like to see persistent local variables in include files
(#static).  (I wound not prioritize #static variables within macros.)

Then it would be nice to have local or private macros.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> That shouldn't make a difference.  A local variable should override any and all
> global identifiers within its scope.  That is the very purpose of local
> variables: so different parts of a program need not be concerned about how the
> other parts do their jobs.  I maintain that having to avoid name collisions
> with the internal workings of external subprograms is totally unreasonable.
> It's the cyber-equivalent of having your lawn mower fail because it uses the
> same type of motor oil as your wife's car.

  The problem is that a #macro is *not* a function. It's much closer to
the substitution macros in a C preprocessor.

  When POV-Ray encounters a name, and this name has been declared as a
macro, it will start parsing that macro, substituting the name with the
contents of the macro.

  I'm not saying this is a good thing. I'm just saying how it works.
It might also require quite a lot of redesigning to change this (which
is exactly what POV-Ray 4 is for.)

-- 
                                                          - Warp

Post a reply to this message

"Cousin Ricky" <ric### [at] yahoocom> wrote:
> I wrote a macro that caused the scene to bomb out because an include file had a
> macro with a *local* variable with the same name as my macro.  This TOTALLY
> DEFEATS THE PURPOSE of having local variables.
>
> This scenario illstrates the problem:

Also:
#declare a = <0,0,0>;
and the first function expecting 'a' to be a float, and doionk!

#declare inneradius = function(a,b,c) { blah }

Post a reply to this message