Null handling in put, network_of, typename, nameof, and grep

[philrz]

In super, operations on null values with put, network_of, typename, and nameof currently produce non-null values. We could choose to do what SQL probably would do if these existed in SQL, which I suspect would be to propagate the null.

$ echo 'null' | super -c "put x:=1" -
error({message:"put: not a record",on:null})

$ echo 'null' | super -c "network_of(this)" -
error({message:"network_of: not an IP",on:null})

$ echo 'null' | super -c "network_of(10.1.2.3, this)" -
error({message:"network_of: bad arg for CIDR mask",on:null})

$ echo 'null' | super -c "typename(this)" -
error({message:"typename: argument must be a string",on:null})

$ echo 'null' | super -c "nameof(this)" -
error("missing")

$ echo 'null' | super -c "values grep('a', this)" -
false

$ echo 'null' | super -c "values grep(this, 'a')" -
error({message:"grep: pattern argument must be a string",on:null})

Details

Repro is with super commit 9ba80d7.

$ super -version
Version: v0.3.0-122-g9ba80d768

These are intentionally covered in this issue separate from #6947, as those all had direct equivalents in legacy SQL, whereas these are our own inventions so in theory we could make our own rules.

I believe it was @nwt who made a compelling argument that SuperSQL should typically propagate nulls even in non-SQL contexts: NULL values are primarily a concern because they come from outside systems or are produced by legacy SQL queries. In a world starting from zero based on super-structured data, rather than relying on NULL we'd probably advocate the use of first-class errors (e.g., error("missing"), structured errors, etc.) as these all convey more meaning than SQL's catch-all use of NULL for all things "unknown". But since nulls are often unavoidable, we could be consistent with SQL by treating it as a placeholder for "unknown" and propagating the null to the result when we encounter a null input to any SuperSQL function/operator.

[philrz]

Just to seed this for future discussion, @mattnibs floated a possible rationale for keeping the error outputs with put in particular.

Consider the following:

$ echo '1 null "a"' | super -c "put x:=1" -
error({message:"put: not a record",on:1})
error({message:"put: not a record",on:null})
error({message:"put: not a record",on:"a"})

One way to interpret the UX here is that when the user tried to use put, they were expecting records in the input. The error values seem very helpful in giving the user a heads up that primitive values were encountered rather than the expected records. In this regard, the fact that the heads-up is given even when the primitive value happens to be a null may outweigh possible benefits of propagating the null in that one case just to rhyme with SQL behaviors.

That said, we also agreed that this is a close call and there's also a simplicity to the support statement of being consistent in doing null propagation. This topic will be revisited down the road.