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

Reply via email to