Brian S. Julin via RT wrote:
>It is that Nil is also semantically special as a RHS of an assignment
>or as a parameter.
...
>This is mentioned in S02.
Some of the specialness mentioned in S02 doesn't happen, such as .ACCEPTS
returning Nil, and getting the default value of an optional parameter.
Those issues probably don't change the logic of this ticket, though.
>Set, as of right now, cannot be parameterized so you only get to see
>the Any case there.
False analogy. The intentional behaviour of the Array is that (by
default) it contains a bunch of Scalar containers, and it is those
containers that (by default) have the funny treatment of Nil. Set, otoh,
doesn't overtly involve any Scalar containers, and in fact immutability
is an advertised feature. So there's no API reason to import Scalar's
behaviour around Nil.
>Or philosphically, Per S02, Nil 'means "there is no value here"',
And yet Nil is a reified object, and so very much *is* a value that
is here. It may indicate the absence of a value in some higher-level
protocol in which Nil is not a relevant value. But down here in the
base language Nil is a visible object.
>so having a set that contains it as an element is incongruous.
Again, that may be so in some higher-level situation in which Nil is not
a value of interest. If you're expecting a set of Ints then getting a
set containing Nil would be incongruous. But where Nil is a value, it
would be incongruous to be unable to put it in a set. It's literally an
axiom of set theory that for every object there exists a set containing
that object. (Note that you need a set theory that includes urelements,
to match the Perl 6 situation.)
>If there is a compelling use-case for allowing Nil in a Set,
I find the intrinsic concept of the set to be pretty compelling.
>probably require using set() rather than Set.new() as we can
>call that a literal.
I don't follow this argument. There doesn't seem to be any rule against
.new() methods accepting a Nil argument as Nil:
> Pair.new("foo", Nil).value.WHICH
Nil|U15269208
Trying things out now, I see that the behaviour of the test cases with
which I started this ticket has changed, and that currently set()
and Set.new() do actually behave differently. (In the original bug
report I didn't distinguish between set() and Set.new(), not seeing any
difference.) set() now accepts a Nil element, and Set.new() accepts Nil
as a sole argument; the substitution of Any now happens only for Set.new()
and only when there's at least one other argument:
> set(Nil)
set(Nil)
> set(3,Nil)
set(3 Nil)
> set(Nil,Nil)
set(Nil)
> Set.new(Nil)
set(Nil)
> Set.new(3,Nil)
set((Any) 3)
> Set.new(Nil,Nil)
set((Any))
That's pretty weird. The subject line of this ticket still seems
applicable.
> you'll note List.new wont transcribe
>Nil either.
That looks like a separate bug.
-zefram
