On 6/22/20 4:18 PM, Cousin Ricky wrote:
> Warning: non-newbies will face palm.  Three times.
> 

I think you're being to hard on yourself. Pretty much anytime I go back 
to something after a while, I see issues with what I did previously! :-)

POV-Ray doesn't have name spaces which would be a help with name 
collisions.

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:

//---
// #declare _a = 1.0; // Causes issue for Fn*s

#declare Fn00 = function (_a,_b) { _a*_b }
#declare Fn01 = function (_a,_b) { _a+_b }

#declare _a = 1.0;  // This OK
#macro Mc00 (_a,_b) (_a*_b) #end
#macro Mc01 (_a,_b) (_a+_b) #end

#debug concat("Fn00(3,3) = ",str(Fn00(3,3),2,3)," () \n")
#debug concat("Fn01(3,3) = ",str(Fn01(3,3),2,3)," () \n")
#debug concat("Mc00(3,3) = ",str(Mc00(3,3),2,3)," () \n")
#debug concat("Mc01(3,3) = ",str(Mc01(3,3),2,3)," () \n")

#error "\nStop before render."
//---

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?

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. Plus eval_pigment I 
moved to math.inc, as Eval_Pigment, because it's a macro not a function.

Using your example, instead of the following in math.inc :

// Adjusts values in a specified range [Rmn, Rmx] to the specified
// range [Min, Max]
#declare adj_range2 =
   function (x, y, z, _Math_INC_OMn, _Math_INC_OMx) {
  ((x - y)/(z - y))*(_Math_INC_OMx - _Math_INC_OMn) + _Math_INC_OMn
   }

I have in functions.inc :

// Adjusts passed (x) values relative to a specified range [Rmn, Rmx]
// to a new value relative the specified range [Min, Max]. Normally (x) 
// in input range, but it need not be.
#declare F_adj_range2 = function (x,y,z,_mn,_mx) {
   ((x-y)/(z-y))*(_mx-_mn)+_mn
}

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.

Bill P.

Post a reply to this message