On Sun, Mar 29, 2009 at 10:57 PM, Mark Lentczner <[email protected]> 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
