hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/22/21 12:13 PM, jr wrote:
>> ...  did I misread yr point?
>
> :-) Suppose, I think so. We want the #ifndef to only look at the tokens
> passed on the macro call.

the documentation is pretty .. explicit on optional macro args and "reliable"
testing requiring 'local.' (dictionary) -- highlighted box.


> The code can of course be correct, my point is
> the option checking code can be wrong - thereby allowing definitions
> into the macro by a path other than the call parameters/tokens.

I was surprised to see there's a way to "smuggle" an undeclared identifier into
a macro, but yeah, "caveat emptor", as BE might say.  :-)


regards, jr.

Post a reply to this message

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

William F Pokorny <ano### [at] anonymousorg> wrote:

> I didn't want to think about this having already
> quite a mess in my head, but my head has.

<Mr Smithers>   Exxxxxxxcellent...  </Mr Smithers>

Welcome to my daily reality.

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

Yes.

And then it would be easy enough to write a macro that gets called and tests
what that thing is, to address your later concerns.
If I can do #read (OpenFile, Thing) and then find out what Thing is before I
further process it, then that's perfect.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.
> > ...
> 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.

back when I used to be real good at giving people headaches.  ;-)


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

sounds good, having a design that returns a bool is v elegant.  and should work
well, eg, when writing a macro for "public consumption" since I could provide
what (argument type) I look for and compare it to the parameter supplied.

(there's lots I'm not clear on, say, 'array [2][2][2]' would compare equal to
any size 3D array of same float/vect/whatever, and such, but like the
design/idea)


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

had not envisaged anything as sophisticated.  thought if 'istype()' returned an
integer value corresponding to type[*] of "foo", and the documentation has a
(lengthy) table with suggestive but not used symbolic names (derived from the
underlying enum) and their numeric values.  anyway, past.  :-)

[*] coded presumably to keep the actual number of "types" down.


regards, jr.

Post a reply to this message

Op 23-5-2021 om 16:31 schreef Bald Eagle:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> I didn't want to think about this having already
>> quite a mess in my head, but my head has.
> 
> <Mr Smithers>   Exxxxxxxcellent...  </Mr Smithers>
> 
> Welcome to my daily reality.
> 
Been there...

-- 
Thomas

Post a reply to this message

Am 21.05.2021 um 23:31 schrieb Tor Olav Kristensen:

> I take it that you would like to be able write things like cos(v0) and then the
> cos function will be applied to all of the components of the vector. If so I
> second that. But only if that if is done with a built in functionality. I don't
> like the macro's we currently have in the include files for such things.

Yeah, no. I don't think that's going to happen. Not as a generic syntax. 
Not within the lifespan of this parser, anyway.

Post a reply to this message

Am 22.05.2021 um 13:33 schrieb jr:

> thinking that what your + CR's (ingenious) posts demonstrate is just how much an
> 'istype()' like function is needed in SDL.  (I've a feeling it would not be too
> difficult to implement, a developer's perspective would be good)

"Pfffffffaaaaaaaaaaaaahahahahaha! BWAAAAHAHAHAHAHAHA!"
(*manic laughter*)
-- Anonymous developer.


Keeping track of the type of things IN THE PARSER ITSELF is painful 
enough... add to that the trouble of coming up with a nice elegant 
syntax, questions such as whether this should work only on variables, or 
also literals or even complex expressions...

... oh, and then add to the mix that the parser doesn't go, "ah, let me 
evaluate and see what the result of this expression is", but rather "ah, 
I expect this particular type here; let me see how the following makes 
any sense under that presumption"...

... ah, and let's not forget arrays. Arrays and array elements are fun. 
Hooray for how the parser handles arrays, and their elements. Yaaaaaay...


Yeah. Multiple cans of worms.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:


> ... ah, and let's not forget arrays. Arrays and array elements are fun.
> Hooray for how the parser handles arrays, and their elements. Yaaaaaay...

He's BA-aaaaaaaaaaaaaaaaaaaaack!!!




OK, although I thought at first it might be a girl, I must admit that my next
guess was that it was the parser.  I sat here, sipping my gin & tonic, slowly
shaking my head in sadness...  "That poor boy.  It had to be the parser.   He
shouldn't have gone and fiddled with it like that.  It's too dangerous.
Everyone knows that.  Others have tried - and failed.  That damned parser ... it
finally broke him...."





"I mean that, for nearly 20 years developers have been searching through this
vast parser.  It's not something to be taken lightly.  No one knows its secrets.
 It's like nothing he's ever gone after before..."

Post a reply to this message

Am 27.05.2021 um 02:45 schrieb Bald Eagle:

> OK, although I thought at first it might be a girl, I must admit that my next
> guess was that it was the parser.  I sat here, sipping my gin & tonic, slowly
> shaking my head in sadness...  "That poor boy.  It had to be the parser.   He
> shouldn't have gone and fiddled with it like that.  It's too dangerous.
> Everyone knows that.  Others have tried - and failed.  That damned parser ... it
> finally broke him...."

Dang, how am I supposed to cry myself to sleep after reading THAT ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 22.05.2021 um 13:33 schrieb jr:
>
> > thinking that what your + CR's (ingenious) posts demonstrate is just how much an
> > 'istype()' like function is needed in SDL.  (I've a feeling it would not be too
> > difficult to implement, a developer's perspective would be good)
>
> "Pfffffffaaaaaaaaaaaaahahahahaha! BWAAAAHAHAHAHAHAHA!"
> (*manic laughter*)
> -- Anonymous developer.
>
> Keeping track of the type of things IN THE PARSER ITSELF is painful
> enough... add to that the trouble of coming up with a nice elegant
> syntax, questions such as whether this should work only on variables, or
> also literals or even complex expressions...
>
> ... oh, and then add to the mix that the parser doesn't go, "ah, let me
> evaluate and see what the result of this expression is", but rather "ah,
> I expect this particular type here; let me see how the following makes
> any sense under that presumption"...
> ...

and yet, WFP's current 'is_type()' is an excellent start on all that.  the thing
is that _any_ "introspection" support in SDL would be a step forward.


regards, jr.

Post a reply to this message