On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
> POV-Ray doesn't have name spaces which would be a help with name 
> collisions.

Yes, that certainly would help!  It could resolve the disagreement I 
have with jr. over macro name persistence.  I would love it, although it 
would be massive work for the dev team.  Fixing the local variable and 
function formal parameter problem is far more important and should be 
prioritized.

> That said, the major issue I see is not having a 100% reliable way to
> avoid a declare in an include causing problems for a function parameter
> in another include or scene. Namely something like:
> 
> [snip]
> 
> We have the convention today users should not declare IDs with lower 
> case characters because such things might become, or might already be, 
> SDL keywords. What I'm thinking about for povr is adding checking such 
> that users cannot declare/local a name with only (lower case ascii, _) 
> characters. #declare _a =... would be a parsing error.
> 
> With this in place, I think it would then be the case we could always 
> use something like _<lowercase_parm> for all our parameters without 
> worry of collisions. The _ leading character would never be part of a 
> keyword.
> 
> Am I missing something with this planned approach?

I suppose it could work.  It could potentially break old scenes, but I 
don't suppose many such scenes exist.  None of the stock include files 
have any such names that I can find.

How widespread are you recommending this convention?  It would violate 
the existing Object Collection namespace conventions, unless we amend 
the conventions.  Since Chris Bartlett disappeared, I don't know if we 
even have a formal mechanism for deciding Object Collection policy.

> 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.

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.

> 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.

> 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.

I personally use fn_ or Fn_, because I already use f_ for finishes.  Of 
course, I can always distinguish between my finish and inbuilt functions 
by noting the one or more capital letters in my finish.

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?

Post a reply to this message