The biggest problem I see is finding a good use for such null value.
In many cases where a null value would make sense, J/APL found a different
way of making something useful out of what would otherwise be an error,
e.g.
'abcX' {~ 0 1 2 i. 0 2 1 0 3 0 100
acbaXaX
i. could return null if not found, but would not allow indexing an array
returning a default value X as above.
It could as well be used for non-defined names, but this would get in the
way of undefined names being interpreted as verbs.
Another issue I see is that it would not have a type (or even more fun, it
could be referring to itself as type). What would the effect be of having
such value inside other arrays? E.g.:
_. 0} i. 5
Would it be transparently converted to the "destination-type"?
That said, I guess we have a precedent for type confusion with empty values:
'', i. 3
0 1 2
$''{i. 3
0
Curious to see what comes up more on this deceivingly simple concept of
null.
Jan-Pieter
On Tue, Feb 8, 2022, 22:08 Henry Rich <henryhr...@gmail.com> wrote:
> Don't worry - I don't expect we will ever find a spec that will make _.
> fit easily into the primitives. But it doesn't hurt to think about it.
>
> 128!:5 will also check for NaN.
>
> Henry Rich
>
> On 2/8/2022 3:30 PM, Clifford Reiter wrote:
> > I am not cheering on work on _.
> > but they can be found:
> >
> > x=: 1 2 _. 4 5 8.8 _. _ __
> >
> > x~:x
> >
> > 0 0 1 0 0 0 1 0 0
> >
> >
> > _. is the only number not equally to itself.
> >
> > A bit of J humor
> >
> >
> >
> >
> > On Tue, Feb 8, 2022 at 3:23 PM Hauke Rehr <hauke.r...@uni-jena.de>
> wrote:
> >
> >> answeres below
> >>
> >> Am 08.02.22 um 21:12 schrieb Henry Rich:
> >>> Generalities may spur the imagination, but to use _. we would need a
> >>> detailed spec for what every verb would do given indeterminate input.
> >>> Where would it appear in the collating sequence?
> >>>
> >> Collating:
> >> maybe I’m naive but I thought it wouldn’t matter much
> >> as long as it’s defined
> >>
> >> for the verb spec, I thought my desription was complete
> >> I’ll take another look
> >>> If _. doesn't match _., how would I find the number and location of _.
> >>> values in an array?
> >>>
> >> part of the i. family belongs to what I called selectors
> >> so I don’t see a problem there (but you need to know the correct idioms)
> >>> The fact that Roger didn't find a way to integrate _. into the language
> >>> should put us all on warning that the problem is very hard.
> >>>
> >> absolutely.
> >> Is there documentation of what thought has already gone into this?
> >> I’m trying to figure out where those problems are I don’t see yet.
> >> (which doesn’t tell anything about those problems but about me:
> >> currently, I’m unable to see them)
> >>> Henry Rich
> >>>
> >>>
> >> --
> >> ----------------------
> >> mail written using NEO
> >> neo-layout.org
> >> ----------------------------------------------------------------------
> >> For information about J forums see http://www.jsoftware.com/forums.htm
> >>
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> --
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
