HaloO
Jon Lang wrote:
Larry Wall wrote:
eqv and === autothread just like any other comparisons. If you really
want to compare the contents of two junctions, you have to use the
results of some magical .eigenmumble method to return the contents
as a non-junction. Possibly stringification will be sufficient, if
it canonicalizes the output order.
Perhaps there should be a way of disabling the autothreading?
I consider stringified junction comparison as second class that
we don't use for other objects either. An .eigenmumble definitely
needs a nicer name. So, don't we have an item enforcement operator?
If that would discharge junctions to mere objects we would have:
my $a = all(1,2,3);
my $b = $a;
if item $a === item $b { say "junctions are identical" }
And then we can invent some short form of that. Things that come
to my mind are =i=, =$= and =^= where the latter nicely reminds
one of the one() junction and also is the indicator for the meta
level where junctions loose their autothreading power and become
objects.
[..] and simply extracting its contents into a list or set won't
always do, since it might be Junction-specific details at which you
want to look.
Conversion to another type violates the requirement for === that
two objects of different types cannot be identical.
We have other operations that should not autothread but demote
junctions to objects:
any(1,2,3) ~~ Junction
Here it hardly makes sense to expand that to
1 ~~ Junction || 2 ~~ Junction || 3 ~~ Junction
Note that this demotion to object means that
any(1,2,3) ~~ Int
evaluates to false because the lhs is of type AnyJunction of Int.
To me this is the same as
[1,2,3] ~~ Int
which is false because there is an Array of Int not an Int.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
