Re: Fun with junctions (was Sets vs Junctions)

[Rod Adams]

Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 12:41:19AM -0600, Rod Adams wrote:
 

Of course we'll always have C<grep>. But this is Perl, and I want YAWTDI.
After all, another way to test membership was just added, whereas before 
you pretty much just had C<grep>.
   

...another way to test membership was added...?
 

$x == any(@y);
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.


And what happens if you attempt to evaluate a junction in a non-boolean 
context?
   

I dunno, which context are you concerned about?
  $a = any(2,3,4);
  $b = ? $a;                 # boolean context, $b == true
  $n = $a + 3;               # numeric context, $n == any(5,6,7)
  $s = $a ~ 'x';             # string context, $s == any('2s', '3s', '4s')
  @l = ($a);                 # list context, @l == (any(2,3,4))
 

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 believe this generates 243 lines of text. IMO, this is not desirable. 
However, if the majority of people out there are fine with this 
behavior, I'll let it rest.

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.

For clarification, is the type of 3|'four' == Junction|int|str?
And I've yet to receive a good answer for what C<3/any(0,1)> does to $!.
-- Rod Adams