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