POV-Ray : Newsgroups : povray.bugreports : Macro parameters with the same name : Re: Macro parameters with the same name Server Time
29 May 2023 23:35:13 EDT (-0400)
  Re: Macro parameters with the same name  
From: Bald Eagle
Date: 22 May 2023 15:40:00
Message: <web.646bc4e4399b0b101f9dae3025979125@news.povray.org>
> 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.