Handling MATCH and "Falsey" Types

Development Semantics
1

MATCH has a fundamental safety issue:

>> match [null? integer!] 3
== 3

>> match [null? integer!] "notaninteger"
== ~null~  ; anti

>> match [null? integer!] null
== ???

If it returns NULL then you have a conflation--the match succeeded, but is returning the same signal as "didn't pass" signal. :frowning:

2 Likes
Conflation vs. Safety, RETURN and "Heavy" Null
2

... and if blank! becomes truthy as per your other post there’s one less case to worry about.

1 Like
4

...aaaand...with Flexible Logic.... Now We Don't Have To Worry About FALSE (or NO, or OFF) Either!

We're down to just one "branch inhibitor": The ~null~ antiform (and maaaaybe ~NaN~)

So it seems the options are:

  1. Don't worry about it. If you write match [logic?] 1 = 2 you get back a ~null~ antiform and should you write an expression like if (match [logic?] 1 = 2) [print "Match!] you get what you deserve.

  2. Error on it, e.g. match [null?] null panics.

  3. Have a MATCH:RELAX variant. Let plain match on null trigger an error and if you write if match:relax ... then you clearly know what you're doing, so it becomes like case (1).

2 Likes
5

I Think The Solution Is "Simple"

("Easy, when you know how...")

Just say MATCH errors on NULL input...but then use VETO-in-NULL-out to bypass thatn.

So if you want a NULL => NULL conflation, instead of writing this:

match [null? integer! text!] var-might-be-null

You write this:

match [integer! text!] cond var-might-be-null

:magic_wand:

2 Likes
6

This is a bit silly given the need for typecheck... because we'd like to be able to precisely emulate the typechecking of function parameters (including nulls). It should be able to return a logic result:

>> typecheck [null? integer! text!] null
== \~okay~\  ; antiform

But there are questions of whether it would typecheck with ^META semantics or not. Should it be:

>> typecheck [pack!] pack [10 20]
== \~okay~\  ; antiform

; ...or/and...

>> typecheck [integer!] pack [10 20]
== \~okay~\  ; antiform

I feel that ^META-typechecking is something different, so you'd probably have to say typecheck:meta to get the "either-or"... as opposed to requiring you to "pre-decay" and always ^META checking.

Then, MATCH should be defined in terms of TYPECHECK

It's a lot less worrisome what happens with null and void when you have TYPECHECK if that's what you need.

For pipelining, MATCH of VOID being NULL... with match of NULL being illegal... just seems best.

If there is no MATCH:META (as there hasn't been so far) then worries about "what if you actually wanted to match void" go away, but maybe that's too prescriptive. :thinking:

I think I'm willing to live in a world with TYPECHECK giving okay/null with a :META option, and MATCH forcing decay with no :META option and interpreting VOID as VOID-in-NULL out, while erroring on null.

If MATCH is easy to write built on typecheck it's less of a concern. Change it if you don't like it.