HaloO,
Luke wrote:
> I just proved that < is not transitive.
>
> I can do that for every boolean operator that Perl has. They no
> longer have any general properties, so you can't write code based on
> assumptions that they do. In particular, testing whether all
> elements in a list are equal goes from an O(n) operation to an O(n^2)
> operation, since I can't make the assumption that equality is
> transitive.
I fully second this. I guess the axiom of excluded middle simply doesn't
hold for the four junction types, nor are they ordered.
(Sidenode as non-native: is the last usage of 'nor' incorrect?)
But so will be many other types.
Could someone point me to a mathematical paper or general material what
axiom system applies to junctions?
> So my original point was that, as cool as junctions are, they must not
> be values, lest logical assumptions that code makes be violated. I
> can tell you one thing: an ordered set class assumes that < is
> transitive. You had better not make an ordered set of junctions!
With a certain stricture on defining the meaning of tokens like < I
think Perl6 shouldn't join poor C++ with its fixed set of operators
to overload ops arbitrarily with unrelated meaning. Unicode has enough
to offer. But back to the point that Luke made: all comparison ops don't
apply to junctions which spoils a big advantage and deminishes junctions
to a nice form to avoid chained boolean connectives like || with an any().
To me junctions always felt more code like than value like. They
are even some kind of meta ops that consume boolean comparison ops
in terms of another boolean connective (any => or, all => and, etc.)
Why not reflect that in the syntax and make them like for, map,
grep etc? I mean with the junction name in front:
if all( @new_coefficients < @prev_coefficients ) {...}
or Brent's example
if any( $active eq ['all', keys %to] ) {...}
The desugared forms would be simple ternary calls:
if any( &infix:{'<'}, $active, ['all', keys %to] ) {...}
The return value would need to be lists of tuples to allow
combining junctions:
if any($x < all(@values > 0))
That latter property also gives
for all(@values > 0) -> $x { say sqrt $x }
And as all other code types junctions are subject to currying
and later usage like other code refs
&x_in = any.assuming( lhs => $x, op => &infix:<==> );
if &x_in( @array ) {...}
With (curried) junctions travelling in & vars I guess people
have less problems with the auto-threading behaviour as well.
Hmm, and we win back the three single character infix ops |, &
and ^. The simple example
if $x == 1|2|3 {...}
then reads
if any($x == [1,2,3]) {...}
I admit though, that the any might be optically attached to the
$x and not to the implicitly hyperated ==. Thus the idiom needs
to be spelled
if any([1,2,3] == $x) {...}
TSa.
