On 3/27/23 17:32, Bald Eagle wrote:
> Speaking of sorting, I'm thinking that it would be a handy thing for devs,
> example scenes, documentation, and the kind of oddball experiments that people
> like me conduct - to have all the keywords numbered, just like the internal
> functions.

Given the code base, we currently need to avoid fixed number to keyword 
associations. While the number to inbuilt function name associations are 
more stable than the number to keyword ones, as a soft rule, none of the 
associations are fixed until the code's compile and link is complete.

We can create indirect 'type' to number associations at parse time in 
the form of a dictionary for a particular executable. We do this in povr 
within the shipped setidtypes.inc file.

---

You and jr have both suggested, being able to work with a keyword 
'index' of some kind as a way to, say, maintain documentation in a 
database. A good idea. Today the database keys need to be strings(a).

The next release of povr (R7 v0.6.1) implements two new SDL functions in 
word_is() and word_get(). These access and make use of 18 internal 
arrays of token information relative to the active version of 
POV-Ray(povr). The 18 arrays break down into three categories.

Previous tokens (back to through v3.6) which are out (o prefix); Tokens 
included in the current code (i prefix); Lastly, tokens which are new (n 
prefix) compared to the prior major release (v3.8 beta 2). See the, 
initial, attached text documentation for more detail.

The aim, for me as much as anyone, is to create methods for the 
POV-Ray(povr) executable to provide initial hooks / 'string indexes' for 
creating and maintaining documentation; Methods for doing parse time 
checks for active keywords, directives, functions, etc.

Aside: In doing this work, I turned up that, at povr's v3.8 branch 
point, there was a new keyword called cmap related to ttf text objects. 
On the parser back up for the v3.8 release, 'cmap' got dropped. I need 
to sort out what to do with 'cmap' for povr as it's something new that I 
didn't know was in my povr fork! (It's probably still in the v4.0 code 
base too, but I did not check)

Bill P.

(a) - Even string / token indexing comes with complications.

Directives, for example, still, mostly, come in two forms as with 
'version' and '#version'. Some like #default are not really SDL 
directives and should be coded as default{}.

A new to v3.8 feature like global and local dictionaries, made use of 
the the token 'global' which had been used with photons in earlier 
POV-Ray versions - depending upon compile time options. Knowing there is 
a 'global' token is a good start, but, then there is the detail. We all 
know, quite a few keywords have multiple uses / applications.

Back to v3.6 at least there were functions coded up in various shipped 
include files that, by name, look like lower case inbuilt keywords or 
functions. I've either replaced these with true inbuilt forms - so 
behavior is not dependent on included files - or I've deleted the lower 
case function code and created versions with upper case characters so it 
is clear the functionality is NOT inbuilt, but is being declared 
somewhere. For example, a function 'even()' was long defined in 
math.inc. With povr it is now F_even() and defined in munctions.inc 
calling M_even() if need be. M_even() being a shipped, 'munction', a 
macro defining & compiling a global function, once, on need.

It's simple except where it's complicated. :-)

Post a reply to this message

Attachments:
Download 'word_is__word_get.txt' (5 KB)