I was referring only to the properties of _., which to my knowledge have
never been adumbrated.
Henry Rich
On 2/8/2022 12:23 PM, 'Pascal Jasmin' via Programming wrote:
Not sure what you mean by " made it an error to create _. in a computation"
1 2 ({ :: _.) ("0 _) 3 4
4 _.
_.("_) 3 4
_.
Roger did a great job with "transparent/silent support" of i.0 in functions
(typically they return i.0)
A full spec for this 'mysterious subject' would be welcome.
Is that a reference to null handling, or to dictionaries? to bind proposal?
On Tuesday, February 8, 2022, 11:53:46 a.m. EST, Henry Rich
<henryhr...@gmail.com> wrote:
Well said! Roger in the end gave up and made it an error to create _.
in a computation, leaving unspecified what should happen if a
preexisting _. is used as an argument.
A full spec for this 'mysterious subject' would be welcome. Then we
could try to implement it.
Henry Rich
On 2/8/2022 11:08 AM, Raul Miller wrote:
The characteristics of the null value have rather routinely introduced
errors in programs because of its non-intuitive characteristics.
It seems clear why we should want null -- null allows for lazy problem
specification, allowing the designer to not specify some data
elements. But correct handling of null has proven to be a rather
mysterious subject.
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
