On 6/23/20 2:25 PM, Bald Eagle wrote:
> 
...
> 
Aside: I see my response is one where the formatting got wonky. Unsure 
why it happens. I've looked for offending settings in thunderbird. Maybe 
particular newsgroups or original quoted text with certain characters a 
trigger? I don't know. Apologies, but I don't see the issue on sending.

-----------

First, reminding everyone 'povr' is not POV-Ray. I'm combining my 
responses and when I start to think about major revisions to POV-Ray's 
SDL, I begin to think seriously about bindings to lua, tcl and python.

--- The _<lowercase> arguments would be the way to avoid parameter 
collisions. Nothing required, but if you don't want trouble...

--- On the idea of per include file generated unique names(1) and 
sorting on include order as a way to decide which 'Thing1' you want. 
Includes very often include other files. It can be an unstable tangle. 
The 'topological sort' can change relative to low level includes based 
on adding other includes, user settings, macro settings, etc. We 
struggle with these same ordering issues in c, c++ header files as jr 
pointed out. Most programming languages have collision issues / scope 
issues which you have to understand(2) - even with namespace support(3).

(1) - In my tcl library I have a UniqueName command which uses a global 
counter to create unique names. The counter value gets used as a suffix 
to create, say, 'Union_0123' and there are options for padding and 
delimiting characters. This generated unique id approach works well in 
languages with good 'list' (c++ std::vector) support. It has the 
exposure things can blow up storage wise if you aren't careful. I've 
found it easy to duplicate.  Today, POV-Ray internally flattens / 
duplicates - excepting meshes and a few other things. Perhaps, not a bad 
approach practically - if we had the list support.

(2) - Excepting those languages which never allow re-definition/undef 
within any given scope. This is the central concept used in functional 
programming languages. I'm toying with povr working in this way - for 
non SDL programming elements (objects, textures, macros, functions). 
Namely all name collisions and undefs being illegal for classes of 
things not needed for program control.  Toying != knowing how. :-)

(3) - Most namespace languages to which I've been exposed support a 
'using <namespace>::min' sort of declaration. These often get used - 
because people don't like to type - but, allowing the shorthand can 
weaken the namespace protections.

--- On jr's point about no type checking. I think we are not too 
exposed. While there is no strict up front type checking, it looks to me 
like the parser tracks the current id types so you cannot incorrectly 
use the wrong type due a bad/unfortunate assignment somewhere.

--- On making the lower case named functions in math.inc inbuilt. I 
might with some/all. I'm ever refining. Everything takes time and nearly 
always more than I first imagine. Step one for me was just getting clear 
what they really were and moving them to functions.inc where I've 
already slowly been changing f_agate and similar wrappers to inbuilt 
functions.

--- On eval_pigment / Eval_Pigment (and alias capability). I've never 
liked eval_pigment! It's not inbuilt, but we talk about it like it is. 
The functionality is already inbuilt. It's this:

     #include "strings.inc"
     #declare Vec  = <1,2,3>;  //                       *** ***
     #declare FnPig00 = function { pigment { rgb <0,1,0,0.2,0.3> } }
     #declare Rslt = FnPig00(Vec.x,Vec.y,Vec.z);
     #debug concat("   ",CRGBFTStr(Rslt,2,2),"\n")

The problem with things like eval_pigment and alias capability is they 
hide the actual code/functionality mostly on the argument of less 
typing(4). If you want to type less, add hot key sequences to your 
editor to insert code templates.  There's a place for the ability to 
alias or redefine inbuilt functionality in a language, but it should not 
be generally used. It makes things harder to learn and harder to debug. 
I was once handed code to debug where the user had, almost completely, 
redefined the actual input language with aliases.

I cannot add Eval_Pigment to texture.inc. The only include files 
currently packaged with povr are:

     arraycoupleddf3s.inc  functions.inc  rand.inc    strings.inc
     arrays.inc            math.inc       shapes.inc  transforms.inc

My povr approach is includes will be in their own code repository. 
Except rarely where what's in the include is essential to core 
functionality. I've moved Eval_Pigment to math.inc for now as core 
functionality, but it's on my 'maybe it should just go away' list.

(4) - And, yep. I don't like the DBL, SNGL in our source code since 
v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
years back which then never got adopted. PRECISE_FLOAT now needs to be 
yanked at some point from povr and I'd like to drop DBL and SNGL too. 
Today you can find the bare 'foat/double' declarations in the source 
code depending on who wrote what. This makes it unlikely we can really 
ever change DBL to be anything but double, for example. Certainly not 
without a lot of type conversions even if, by some chance, everything 
works correctly.

--- On additional lower case constants becoming in-built. I'm not 
opposed so long as they are very common. V38 added tau.

Bill P.

Post a reply to this message