Many other computer languages deal with non-data just fine, some old,
some new:
SQL 92: NULL
Ruby: nil
Python: None
Objective C: nil
The nice thing about Ruby's OO methodology is that if you want to
extend a particular operator onto nil, you can:
class String ; def empty?(v); v.length == 0; end; end
class Array; def empty?(v); v.size == 0; end; end
class Hash; def empty?(v); v.size == 0; end; end
class NilClass; def empty?(v); true; end; end
# test whether obj is empty or nil
if obj.empty?
...
On Sep 5, 2009, at 11:27 AM, Roger Hui wrote:
> NO DATA, like NaN, should be treated with caution.
> For example, what are the answers to the following
> questions?
>
> NODATA = NODATA
> NODATA = 314159
> NODATA ~: NODATA
> NODATA > NODATA
> $ NODATA
> 3 $ NODATA
> NODATA $ 3
> 3+NODATA
> 0 1 2,NODATA
> /: 0 1 2,NODATA
> < NODATA
>> NODATA
> NODATA e. a.
>
> Last but not least,
>
> NODATA=NaN
>
>
>
> ----- Original Message -----
> From: James C Field <[email protected]>
> Date: Saturday, September 5, 2009 11:13
> Subject: Re: [Jchat] wishlist adverb: ignore indices
> To: Chat forum <[email protected]>
>
>> Raul Miller wrote:
>>> On Thu, Sep 3, 2009 at 4:22 PM, James C
>> Field<[email protected]> wrote:
>>>
>>>> What do you want the "fill" marker to be?
>>>> Blank fill for character or zero fill for integer? Real or
>> imaginary?>> Perhaps a simple extension such as used in APL TAKE.
>>>>
>>>
>>> I do not understand how your question relates to what I
>>> want: What is a "marker"?
>>>
>>> But, yes, fill would be 0 for numbers, space for characters
>>> and ace for boxes.
>>>
>>>
>> A MARKER in my conception is an indication in or of a data field
>> that no
>> data is present or offered. Data is simply absent. Programmers
>> frequently employ subterfuges or special flags or tags to
>> indicate that
>> there is no data in a field. Theis practice could be
>> characterised as a
>> kludge.
>>
>> NO DATA should be a universally understood condition in data
>> storage and
>> retrieval. APL take used zero and blank as fill.
>>
>> I propose that NO DATA should be a useful alternative fill.
>> Obviously
>> this is complicated in its implications but, I think, worth thought.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
