To be honest, I’m a bit confused by the stated difficulty.
I haven’t worked much with that value (yet) but this is
what I thought it was meant to/would want it to work like:
I got to know _. as a value that may be present in data,
usually not first occurring as the result of a computation
other than retrieving input (files/network/tty/socket/…)
but fix point of any calculation. In J, this would apply to
any cell containing _. – at least that’s what I would expect.
(for any function processing/altering data; mere selectors
are to be considered to retrieve references into unaltered
data in this respect)
A problem in current J is
datatype _.
floating
when actually (in my opinion) it should be generic (datatype generic),
to be used in arrays of any shape and datatype. Fill is determined
by the datatype, and if it’s generic (value _.), fill is _. as well.
Determining result shape? Try cells until you get the first non-_.
Exhausted? Return that array of _. Else reshape each _. result gathered.
Doesn’t sound complicated to me.
Would this mean too much trouble (other than compatibility)?
NB.
Just as any array literal L with 0=>./$ L imo is generic
no matter if it’s (n$0)$A with A=i.0 or A='' or A=}.a: or whatever
But that one would break too much working code so I don’t expect
any changes there. And it’s good to have one such value only,
I’d stick with _. for that purpose (null/nil/void/none etc)
I actually depend on 'literal'-:datatype'' etc myself.
This lends itself to some neat techniques, cryptic though
they may appear.
Am 08.02.22 um 17:53 schrieb Henry Rich:
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.
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
