On 5/22/21 8:02 PM, Bald Eagle wrote:
>> Perhaps we need an istype() function like jr suggested.
> It would be great, especially since then we could type thing in CSV files as
> they're being read in, and would need foreknowledge of the file structure.
> 
> Alternatively, we could use a trap() or OnError () function that allows
> sequential rejection of blocks of code that would try to operate on the wrong
> type until the code encountered a test that didn't throw an error.
> 

Somewhere in this thread jr had a feeling istype() wouldn't be too 
difficult to implement. I didn't want to think about this having already 
quite a mess in my head, but my head has.

I think something like idtypesmatch() might be relatively simple(1). 
You'd set an id to a reference thing. Then compare other IDs against 
that reference by internal type. The function would return 0 or 1. 
Useful enough?

Once into something like istype(), we at a minimum need to make all the 
types of interest accessible by name in the SDL. Internally there are 
type classes - 'someKindaVector' and so on which would likely be useful 
to have defined too. The implementation complexity rapidly increases, if 
you want to set up or store types for later work in a parser aware way, 
define types priori, ...

Bill P.

(1) - Less controlled variations could store values of types via say 
typevalueof() in float capable 'storage-types' for later float to float 
compares. Note. The type enums within the parser are not constant, but 
change as the parser keywords change. Meaning one would always have to 
run typevalueof() against reference 'things' to get the POV-Ray 
version's baseline type values against which to compare other things.

Post a reply to this message