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

[hostilefork]

@johnk

Why is compose [1 (third [1 2]) 3] not some kind of a range check error?

@hostilefork

Nowadays there's an option on the table for raising definitional errors, which could easily be turned into nulls with try third (...)

>> third [a b]
** Error: Cannot pick 3 of BLOCK! (or somesuch)

>> try third [a b]
== ~null~  ; anti

@hostilefork

So I rather quickly ran into the fact that PICK is shared code with what you get when you are using a tuple. So pick block 3 acts like block.3, and pick obj 'field acts like obj.field, etc.

But there's an important difference: obj.field can run a function. And if you write try obj.field the expectation is that your TRY is processing the result of that function...not errors arising from the field selection itself. :-/

...but TUPLE!s (like obj.field) don't run functions anymore! Only PATH!s (and WORD!s) do!

This means we can raise definitional errors when a tuple-based pick fails (on the last pick step, we don't want to conflate failures on the last pick with earlier missing steps).

PATH!-based picks abrupt fail when the thing you're picking isn't an action, and any TRY is connected to the result of the function you're calling. But it's fine that's different.

Sounds pretty promising! It does make me wonder about what I said regarding the question of if MAYBE should turn definitional errors to NULL. If it doesn't, you'd have to write maybe try a lot...being able to just write maybe when you wanted a void would be better.

Offhand I can't think of any places where you'd be saying MAYBE and not be willing to sweep a definitional error under the rug just as much as you would a null soft failure. I guess I'd have to try it and see if that conflation caused any accidents.

Quick change to add the error and the system boots after minor modification!

I'll keep you posted...