Why Doesn't `(third [1 2])` Trigger A Range Check Error?

Development Semantics
11

Sometimes I get a bit bogged down in the details and forget how well a lot of things are working, because I focus a lot on the tough parts. :roll_eyes:

Definitional errors are certainly slippery, and this new idea that they are in-band for field selection in objects is definitely a blessing in some places... but a curse in others.

Something about PICK-ing is that it actually gets folded into GET-ing when you use tuples. Consider the difference between:

pick:meta foo 'bar

get $foo.^bar  ; distinct from (get $foo.('^bar)) aka (pick foo '^bar)
get $foo.^('bar)  ; how to use implicit meta with a group!

So GET can be unable to succeed in yet more ways...

  1. Lookup of foo didn't succeed (in the PICK that would have been a panic in FOO lookup before pick was called, but it happens during the GET with the parameter it has passed)

  2. Lookup of FOO succeeded, but you can't pick out of it (maybe it's an INTEGER! or something)

  3. The lookup was valid, it's a member, but it was pure unset

  4. The lookup was valid (e.g. let's say to an OBJECT!), but bar doesn't exist as a member (or it's a BLOCK! but an index was used that was out of range--this is considered the same kind of "almost" situation)

  5. And then... the lookup could be valid, it's a member, and it's an ERROR! antiform.

:roll_eyes:

I feel like 1-3 being a PANIC you had to work around some other way, with 4 being a definitional error you could handle with an EXCEPT or TRY was a success, and the arrival of 5 is a pretty big thorn.

This is definitely a pain, leading me to empathize with the annoyance that led to the axing of storing active ERROR!s in variables like in Rebol2.

But there's no turning back on this. "Lift the Universe" has too much upside... by eliminating any particular "moment" at which FRAME!s need to perform transformations on arguments.

I'm still struggling a bit with the idea that meta-picks panic on (4), while non-meta picks use the lack of conflation to allow ERROR! as an out-of-band signal. I'm not really concerned about how this handles if you're doing foo.^bar vs. foo.bar literally, but rather if you wrote get var without knowing whether var is going to cue meta-behavior or not.

There are no specific problems with it yet, but it just makes me uncomfortable.