On Sun, Mar 29, 2009 at 10:57 PM, Mark Lentczner <ma...@glyphic.com> wrote: > What I see here is that there is a tendency to want to think about, and > operate on, the eigenstates as a Set, but this seems to destroy the "single > value" impersonation of the Junction.
In my case, this tendency comes more from a desire to be able to reverse the creation of a junction: you create a (singular) junction from a (plural) list ('1|3|5' === 'any 1, 3, 5'); so I naturally want to be able to (more or less) reverse this process and create a (plural) Set from a (singular) junction. > Further, if one ever calls .!eigenstates() on a Junction, then you have > really bollox'd your code up, as then this code fails if the value you > thought was a Junction happens to be, actually, just a single value! > (Unless .!eigenstates() is defined on Object, and returns a Set of self...) Which is why I'd _want_ eigenstates to be callable on an Object as described - and, in general, _any other_ function that operates directly on junctions should be able to accept Objects as well, treating the Object as a one-eigenstate junction. Otherwise, the moment you write a function that passes a junction as a parameter, your code will break if you ever try to pass an Object in instead. And the only other ways to avoid that would be: 1. to provide a means of testing whether or not something is a junction, or 2. to forbid anyone from ever using "junction" in a signature. > I think what is needed is a "single value" threshing function, which can be > applied to, well, single values. Such a function would take a value and a > predicate, and if the predicate applied to the value is true, returns the > value, else it returns... nothing. If such a function were applied to a > Junction, then the result would be a Junction of just those those > eigenstates that "passed" this function. The "nothings" would not end up > contributing to the Junction. ...that could work. The only catch is that if you ever want to get a list of the cases that passed so that you can operate on them individually, you'd still need a means of extracting the eigenstates from the junction. > Now, I'm not sure I know how to return "nothing" in Perl6, but I'll guess > that undef can serve the purpose, since I can't think of a useful use of > undef as part of a Junction. As Daniel indicated, returning an empty list should work. -- Jonathan "Dataweaver" Lang