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