Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 01:18:53PM -0600, Rod Adams wrote:None of which has been mentioned or defined, so I was forced to assume they didn't exist.
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.My issue is less that lists and sets are radically different. It is muchSince Scalars can be objects that are fairly complex aggregations
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.
that simultaneously hold (or appear to hold) multiple different values at once, this doesn't seem like a strong argument.
s/object/Junction/g above doesn't give me much grief. Extracting
values from a Junction is also done by calling methods or functions.
Of course, if we go this route, we are now saying that the return type signature of a sub is defined by an instance of class Junction.
As I stated in a different message, my latest, fairly careful, interpretation of S09 rendered that autothreading and junctions were not directly related topics, even if I wrongly implied they were several posts ago. Thus the reference that slurpy lists cancel autothreading is not relevant to this issue. But if it makes the rest of the discussion go smoother, assume I've overwritten C<say> with a non-slurpy version that otherwise does the same thing.It was basically a reiteration of my "iterated side effect" argument, which gets worse if you do:And what happens if you attempt to evaluate a junction in a non-boolean context?I dunno, which context are you concerned about?
[...]
@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 would still think that the above would print 243 times. Consider it this way: P5's C<"print"> returns true upon success. Thus, C<say> would could also be considered a boolean function for "Is this printable with a linefeed after it?". So I could then write:
@l = (any(1,2,3),any(4,5,6),any(7,8,9),any(10,11,12),any(13,14,15));
$x = say @l.join(' '));Given the rest of Junction logic defined thus far, I would expect $x be a junction of 243 true/false values.
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')
The fact that it didn't exist until now. Does this mean we can do:
@l = (any(qw/a b c d/) eq any(qw/c d e f/)).values();
and get @l == ('c','d')?But if you go with the Junction is a Class argument from above, I would expect the type would have to be Junction, and then one could query the Junction object as to what types it can mimic.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.
Of course, we could have Junction do some magic, and have each instance create an anonymous subclass that is also ISA whatever types of values happen to be in it at the time.
Which seems fairly heavyweight for something so integrated into the language.
Will I be able to create variables that can hold ints, but _not_ junctions of ints? In other words, is:
my int $x = 3|4;
legal? How do I make it illegal, so as to protect myself from duplicated side effects which may be disastrous in application X? If the above is illegal, how do a declare a variable that can hold junctions, but only of type int? Using my set notation, we get a simple:
my int #x = 3|4;
I'm not certain my creation of a new Set container is the Right Way to be doing things, but it does seem to be resolving or eliminating the issues I see with Junctions. At least in my head. I might have gone insane recently and just haven't noticed it yet.
-- Rod Adams
