On 2020-06-27 11:05 AM (-4), Bald Eagle wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> One just has to keep in mind POV-Ray's scope leakage
> 
>> [2] If you have formal computer science education, you are mortified by
>> these restrictions, wondering how people smart enough to create POV-Ray
>> could have allowed such boneheaded violations of modular practice.  I am
>> assured that the current development team is aware of such problems.
>> Yes, I will keep complaining about the scope leakage until it is fixed.
> 
> This is an area where I've harbored suspicions and trepidation, due to
> subconscious knowledge gathered from reading the newsgroups and docs over the
> past years.
> 
> Jr and I have recently been working on some code, and while implementing /
> rewriting a macro, some recursion was introduced, and a variable identifier was
> passed back into the macro as an argument.  Debugging hilarity ensued.

Ah, yes, I've run across this before.  Take a look at macro CH2RGB() in 
colors.inc.  The parameter HH used to be H before I blundered into the 
pass-by-reference trap and my scene file fell into an infinite loop. 
Thanks to Jerome for figuring out the problem, and to whoever fixed it 
in time for the POV-Ray 3.7 release.

I ran across it again in Lightsys IV.  (That bug was also fixed in 2012.)

Which area are you concerned about, scope leakage, or accidental 
pass-by-reference?

> If I understand it all correctly:
> When you #declare variable N to have some value, and then use N as the
> "temporary" variable name of what gets passed into the macro, and then use
> #local to declare N's new in-macro / in-loop value ....  the global / higher
> level value of N gets redeclared.
> So apparently "POV SDL apparently makes no distinction between passing-by-value
> and passing-by-reference, as other languages do."

I would say that it does, but the distinction is not explicit; the 
distinction manifests in how you express the argument, as you have 
discovered below.

> [snip]
> 
> Now here's the interesting part - which I had NO IDEA was even a thing:
> "turns out, there's a (documented *) way to force POV-Ray to always treat a
> macro argument as pass-by-value.  Add a '+' in front of the identifier name and
> voila, POV-Ray is not "not allowed" to pass-by-reference because we're not using
> an identifier, but an expression.
> 
> so:
>       A(+N)
> will leave N alone."
> 
> http://www.povray.org/documentation/view/3.6.1/243/
> [snip]

I have no problem with this.  At the *very* worst, it's a "I don't like 
the way this works so it must be a bug," but I won't even go that far. 
While pass-by-reference is dangerous if misused, it is still an 
important tool, and making POV-Ray strictly pass-by-value would 
compromise its flexibility.  C can be strictly pass-by-value it because 
one can pass an address to effect pass-by-reference.

While I admit it would be nice for POV-Ray to have an explicit 
distinction between pass-by-value and pass-by-reference, I would give it 
a low priority.  POV-Ray's implicit distinction is clearly defined and, 
as you have noted, well documented, confusing though it may be.  As long 
as you are careful with your coding, it is not a problem.

Scope leakage is a different matter.

Post a reply to this message