On Thu, 09 Mar 2017 12:55:58 -0800, zef...@fysh.org wrote: > Brandon Allbery via RT wrote: > >Erm. Isn't Nil a silent Failure? > > It may well represent such a thing, but it is also a reified object. > Putting objects into sets is an operation that's applicable to any kind > of object, and which (for comparison) does in fact work on objects of the > Failure class. Expecting an object to be propagated doesn't assert that > it doesn't represent failure; rather, it's just embracing the reification. > The great benefit of reification is that the object can be processed in > all the familiar ways that are used on ordinary value objects. > > If you want to impose a restriction that failure objects can't go into > some of the places I've tried to put Nil, then in some cases that would > be a sensible decision. It would make perfect sense to restrict Range > endpoints, for example, but it doesn't make any sense to restrict the > domain of Sets. But in any case, wherever such a restriction is desirable > it should be enforced by signalling an exception: silently substituting > a different value sucks. And if your logic for rejecting Nil is that > it represents failure, then presumably the same logic would lead you to > reject objects of the Failure class too, and maybe also Exception. > > -zefram >
The reason this is happening is not that Nil is a pseudo-Failure. It is that Nil is also semantically special as a RHS of an assignment or as a parameter. $ perl6 -e 'my @a; @a = Nil,Nil; @a.perl.say' [Any, Any] $ perl6 -e 'my Int @a; @a = Nil,Nil; @a.perl.say' Array[Int].new(Int, Int) $ perl6 -e 'my @a = Array.new(Nil,Nil); @a.perl.say' [Any, Any] $ perl6 -e 'my @a = Array[Int].new(Nil,Nil); @a.perl.say' [Int, Int] This is mentioned in S02. Set, as of right now, cannot be parameterized so you only get to see the Any case there. The usual "solution" to this in the Array case is to directly bind the element. This is actually discouraged as it is in violation of the GLR "gentleman's agreement" that Array elements are Scalars. Set being immutable, getting a Nil into a set element would require some internals incantation. Nil is not supposed to be used as a generic kickaround Mu instantiation -- it is just not a normal value. Or philosphically, Per S02, Nil 'means "there is no value here"', so having a set that contains it as an element is incongruous. We only let it out into Lists/Seqs because it would be impossible to use otherwise. If there is a compelling use-case for allowing Nil in a Set, it should probably require using set() rather than Set.new() as we can call that a literal... you'll note List.new wont transcribe Nil either.