Cousin Ricky <ric### [at] yahoocom> wrote:

> How widespread are you recommending this convention?

It might help obviate "reading the mind of every Povver" if some mechanism were
implemented to prepend/append some designation to the variables to make them
"unique" to any given include file.

BE23062020inc_var1 = pow(e, i*pi);

Verbose, more work, jr will have an apopleptic fit, but serves as a functional
workaround.

I would love to be able to declare identifiers using some form of formula or
concatenation - though I don't know what that would involve in the source code.

If I wanted a01 through a10, then I could write a for loop that would declare
those identifiers.

#for (N, 1, 10)
#declare Identifier ("a" + str(N)) = pow(N, 2);
#end

(not proper syntax, but you get the _idea_)

And if THAT were possible, then at the top of the include file, one could
#declare INC_PREFIX = "BE23062020inc_";
write a small macro to prepend that to any identifier name, and then

#declare INC(a) = 0;

would be the/a way you'd handle all of the names in that file.

I know we have that parse thing (the name always escapes me) that writes to a
file and includes it back in...

> > Your post touches on other changes I've made in povr. You mentioned
> > math.inc defining - via our scene description language - functions
> > which look like fully inbuilt keywords/functions. We have also the all
> > lower case eval_pigment macro. I think these lower case names bad form
> > and I've changed them to have upper case characters in addition to
> > moving the functions from math.inc to functions.inc.

Why not make them ... fully inbuilt keywords/functions?

> The problem with renaming functions and macros is that it would break
> older scenes.  But keeping the old names alongside the new names would
> solve that problem.  Since these old names are already part of the
> POV-Ray canon, avoiding new keywords with these names should not be a
> problem.

How much does it take to implement an alias system?
It would be ever so nice to be able to rename inbuilt keywords and functions.

> > Plus eval_pigment I
> > moved to math.inc, as Eval_Pigment, because it's a macro not a function.
>
> It seems to me that Eval_Pigment() belongs in textures.inc.

Move it into source code!  :)

> > I want to get to where f_ prefixed functions indicate inbuilt functions.
> > The F_ prefixed functions indicate SDL defined functions shipped in povr
> > include files.
> >
> > Something I've stumbled over is seeing odd(...) in a scene file and
> > thinking it's an SDL keyword - but then not seeing any documentation for
> > it. I might not always be getting today's math.inc odd() in any case. At
> > least if I see the F_ prefix I'll know it's something defined in an
> > include and I need to be careful.

odd, even, and those sorts of functions should be in source code.
I find it ridiculous to include a whole file simply for one little function.
Or have to hunt down the include file to copy/paste the code.

> What do you think of e and o in consts.inc?  I think o would be better
> as O, because the Cartesian origin is normally denoted with a capital O.
>   But Euler's constant is always lowercase e.  Would it be worth making
> a keyword?

YES

Post a reply to this message