Re: Empty? No. Array? No. Has? Yes.

[Coda Highland <chighland@...>]

On Wed, Jul 3, 2013 at 3:21 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
>
> On Wednesday, July 3, 2013, Coda Highland wrote:
>>
>> On Wed, Jul 3, 2013 at 2:45 PM, Eike Decker <zet23t@googlemail.com> wrote:
>> >> It's a brilliant idea, but is "nil" an alias for "nil(defined)" or
>> >> "nil(undefined)"? It'd have to be an alias for "nil(undefined)" to
>> >> avoid breaking "t[#t] = nil" and similar idioms.
>> >>
>> >> /s/ Adam
>> >
>> > If you write "nil", you specify it, so it's nil(defined). The
>> > undefined nil value is only created when it originated from a lack of
>> > specification.
>>
>> Sadly I can't see any way to reconcile "nil" = "nil(defined)" with
>> "t[#t] = nil" being a pop operation. It would be a
>> backwards-incompatible change, and therefore can only be an opt-in
>> behavior, which is of course an increase in complexity.
>>
>> If "nil" = "nil(undefined)" and "null" = "nil(defined)" then it works,
>> at the cost of adding another keyword, but Roberto seems to indicate
>> that doing so would require some additional hierarchy of values. I
>> don't think I understand why.
>>
>> /s/ Adam
>>
> Perhaps:
>
> type(baz)
> -->"nil", "undefined"

Ah, my apologies, I should have written `nil` instead of "nil", as I
was referring to the token itself, not to the type string.

/s/ Adam