On Sat, Feb 12, 2005 at 01:18:53PM -0600, Rod Adams wrote:
> >>My issue is less that lists and sets are radically different. It is much
> >>more a matter of Junctions and Scalars are radically different. Getting
> >>me to accept that a Scalar holds several different values at once is a
> >>hard sell. Especially when you consider duplicated side effects.
> >
> >Since Scalars can be objects that are fairly complex aggregations
> >that simultaneously hold (or appear to hold) multiple different
> >values at once, this doesn't seem like a strong argument.
>
> But, to extract those alternative values from an object, you do
> something special to it, like call a method. Whenever you evaluate the
> object as a scalar, you get a single value back. Quite probably a
> reference to something much more elaborate, but a single value none the
> less. When you do a C<say $obj>, C<say> is only called once.
s/object/Junction/g above doesn't give me much grief. Extracting
values from a Junction is also done by calling methods or functions.
> >>And what happens if you attempt to evaluate a junction in a non-boolean
> >>context?
> >I dunno, which context are you concerned about?
> >[...]
> It was basically a reiteration of my "iterated side effect" argument,
> which gets worse if you do:
>
> @l = (any(1,2,3),any(4,5,6),any(7,8,9),any(10,11,12),any(13,14,15));
> say @l.join(' ');
I'm not so sure it gets "worse" here -- @l.join(' ') gets evaluated
first, and C<join> is called only once because none of its parameters
are a junction. In this case C<join> is going to return a junction
of strings. Similarly, as Scott Duff pointed out, C<say> will be
called only once, since the arguments to C<say> are passed as part of a
slurpy array and as such do not autothread. (No, I'm not entirely
sure what would be output as a result. However, whatever it is,
it should all be on one line, not 243 lines.)
> I also have not seen any good way to avoid the situation. It's now been
> established that one can do a C<.isa("Junction")> to determine that what
> we have is, indeed, a junction. However, once that happens, your options
> are basically to either live with it, or throw an exception. If you're
> given 'cat'|'dog', there's no way to extract 'cat' and or 'dog', unless
> you happened to be expecting 'cat' and 'dog', and test for them explicitly.
Umm, what's wrong with...?
$l = 'cat'|'dog'|'mouse';
@extract = $l.values(); # ('cat', 'dog', 'mouse')
> For clarification, is the type of 3|'four' == Junction|int|str?
I would guess the type of 3|'four' to be int|str, which is also a
Junction, but don't hold me to that.
> And I've yet to receive a good answer for what C<3/any(0,1)> does to $!.
I'm sure that 3/any(0,1) throws some sort of divide by zero exception;
same as 3/0 would, and places the exception into $!. I don't know
that $! must necessarily then be a junction of exceptions, or that the
exceptions would have to be processed in parallel (i.e., as with many
things, processing of the value/list/object/junction stops at the
first exception encountered). But someone more expert than I would
need to provide an answer to that one. :-)
Pm
