 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure how to categorize this, as it does not manifest with
properly constructed SDL; but it lets improper code render to completion
while leaving you scratching your head over why the image doesn't look
right.
Say you're developing a wood macro, and you start with:
#macro MyWood
( Taper, Rings_map, c_Light, c_Dark,
Grain_size, Roughness, Gnarl, Gnarl_size, v_Random
)
It looks good, but you want to add varnish. Your arguments are the
glossiness, the specular highlight roughness, and the varnish's index of
refraction:
#macro MyVarnish (Glossiness, Roughness, IoR)
Finally, you think it would be convenient to combine the two macros into
one:
#macro MyVarnishedWood
( Taper, Rings_map, c_Light, c_Dark,
Grain_size, Roughness, Gnarl, Gnarl_size, v_Random,
Glossiness, Roughness, IoR
)
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
I am glad though, that you found the error - sometimes those things can be SO
hard to spot.
Although it does eat up lines, I will sometimes put all of the arguments on
separate lines just to makes things like that visually stick out.
One thing I have suggested in the past is a way to access from SDL the number of
arguments passed to the macro. First, this would be useful in cases where
optional arguments are used, and conditional processing is needed.
But in your case, I can imagine a little sanity-check sub-macro being called in
the first line of every macro that could compare all of the values of the
arguments looking for equalities/duplicates. Better still would be access to
the macro argument names, or the whole list of argument names as a small array.
You could of course, simply pass everything to the macro as an array, and then
use dimension_size to cycle through all of the elements of the array to do
sanity checks... (I initially wrote "samity checks"... which kinda seemed like
a fitting error :D )
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
I am glad though, that you found the error - sometimes those things can be SO
hard to spot.
Although it does eat up lines, I will sometimes put all of the arguments on
separate lines just to makes things like that visually stick out.
One thing I have suggested in the past is a way to access from SDL the number of
arguments passed to the macro. First, this would be useful in cases where
optional arguments are used, and conditional processing is needed.
But in your case, I can imagine a little sanity-check sub-macro being called in
the first line of every macro that could compare all of the values of the
arguments looking for equalities/duplicates. Better still would be access to
the macro argument names, or the whole list of argument names as a small array.
You could of course, simply pass everything to the macro as an array, and then
use dimension_size to cycle through all of the elements of the array to do
sanity checks... (I initially wrote "samity checks"... which kinda seemed like
a fitting error :D )
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK - I see it now.
I was thinking in terms of the macro CALL, not the macro "constructor".
So yeah, what you're saying now makes a lot more sense.
I can still se where someone may have some reason to want to do it that way,
especially if the second argument is an optional one, but I don't write computer
languages or parsers...
I will say that it's like a second camera in a scene, so there's still the
potential to issue a "duplicate argument found in macro declaration - ignoring
previous instance" kind of warning.
But your point is indeed a valid one, and something for macro writers to be
acutely aware of. (A similar but harder-to-spot error would be having a second
variable declaration later in the scene to overwrite the previous value. Kind
of the reverse of failing to update a counter in a while loop.)
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK - I see it now.
I was thinking in terms of the macro CALL, not the macro "constructor".
So yeah, what you're saying now makes a lot more sense.
I can still see where someone may have some reason to want to do it that way,
especially if the second argument is an optional one, but I don't write computer
languages or parsers...
I will say that it's like a second camera in a scene, so there's still the
potential to issue a "duplicate argument found in macro declaration - ignoring
previous instance" kind of warning.
But your point is indeed a valid one, and something for macro writers to be
acutely aware of. (A similar but harder-to-spot error would be having a second
variable declaration later in the scene to overwrite the previous value. Kind
of the reverse of failing to update a counter in a while loop.)
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/23/23 00:50, Cousin Ricky wrote:
> 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.
In a look at three other languages...
C/C++ (gcc/g++ 11.3.0)considers the duplicate parameter names/ids to be
an error. As does python3 (3.10.6).
The scripting languages tcl (8.6) allows the duplication and it appears
the first setting of the repeated name/id always wins.
In POV-Ray SDL I think the last setting of the parameter will always win
because POV-Ray maintains symbol tables (key -> value hash tables) so
the last time the symbol is set in the current scope is what the value
is thereafter.
If allowing duplicate parameters, I think POV-Ray's last value wins
method more intuitive as inside macros / functions we can always update
the local variable(a). These within code body/block overrides are always
the last setting wins so it sort of makes sense the last time a
duplicated parameter name is set should win out too.
I lean toward the duplication of parameter names being an error. I think
duplicates are far more likely to cause confusion than help.
Bill P.
(a) excepting where languages support constant parameters/variables and
the feature used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2023-05-23 07:08 (-4), Bald Eagle wrote:
> OK - I see it now.
>
> I was thinking in terms of the macro CALL, not the macro "constructor".
>
> So yeah, what you're saying now makes a lot more sense.
Yes, of course the *caller* should be able to reuse the name as often as
desired, no warnings necessary.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
