On 2023-05-22 15:39 (-4), Bald Eagle wrote:
> 
>> Do you see the problem?  I didn't--but neither did the POV-Ray parser.
>> When I combined the macros, I accidentally used the name 'Roughness' for
>> two different arguments.  I spent a week wondering why the final macro
>> didn't give the results I expected.  I think the parser should flag this
>> as a fatal error.
> 
> Well - I would respectfully disagree.
> I would say the the parser ought to issue a warning - "Multiple usage of
> argument name in macro call" - since I can easily envision instances where
> people might want to use named variables in multiple places, rather than rigidly
> partitioning everything into unique special-purpose values such as you are
> doing.
> 
> It's always hard to judge what someone may want to construct, and leaving the
> option open for employing that kind of flexibility to use anything one might
> desire as a macro argument should always be something available to the SDL
> programmer.
> 
> I do agree that we could use some more assistive programming aids and debugging
> tools, but I think a warning would suffice.   Much like we can scale by x*2,
> which is <2, 0, 0> and the parser "knows" (the Dev Team rightly assumes /
> presumes) that the user means to scale in the x direction by two, leaving the y
> and z dimensions untouched - <2, 1, 1>.  We can make degenerate triangles, and
> sometimes even divide by zero, yet the scene successfully parses.
> 
> A fatal error here is WAY too strict / limiting.

No, I stand by my position.

You've seen me complain bitterly about POV-Ray's scope leakage--how a
local identifier can conflict with a macro name, requiring everyone who
shares a macro to avoid any name that the users might think up.  You've
seen users burned because they created an identifier whose name
*happened* to be the same as a formal parameter of a function they
didn't write.  Those are conflicts that should never happen in a
block-structured language, and require elements of a scene to know the
inner workings of other elements that they shouldn't need to know, and
indeed have no business knowing.  Those are situations in which allowing
multiple identifiers with the same name would be the best policy.

Instead, what we have in this case are identifiers with the same name
*in the same context.*  How is the macro to know which instance the
POVer intended where?  What exactly would a fatal error be limiting?

This is not flexibility; it is ambiguity.

As it turns out, POV-Ray appears to choose the latter instance.
Arbitrarily.  It could have been the other way around.  It could have
been random.  Maybe it *is* random, and I just haven't done enough test
cases.

I maintain that this is not analogous to a degenerate triangle; it is
analogous to a degenerate cylinder.  This is not a warning situation; it
is a scenario where, by rights, the parser doesn't really know what to
do.  The construction is useless, ambiguous, and nonsensical.

Post a reply to this message