Luke wrote:
> Okay, fair enough. The reason that I thought it was surprising is
> because 1 and 2 are usually orthogonal patterns.
It depends what they're doing. Matched against a regex like /[12]/ they're
not orthogonal either.
>> > Junctions are logical travesty,
>>
>>Well, that's very emotive, but I don't believe it's either a useful or
>>an accurate characterization. I would agree that junctions can be
>>logically *sophisticated*, but then I'd argue that *all* programming
>>constructs are that.
>
> No, that wasn't emotive,
"Travesty" is not an emotive word???
> that was a logical statement explaining that junctions are not logical.
Riiiiiiiiight. So "Luke's statement is a logical travesty" isn't an
unsubstantiated emotive assertion either? ;-)
> Have you ever heard of generic programming?
>
> How can any *ever* write a sensible generic Set class when you are
> required to know what kind of thing you have in the set?
By restricting the implementation to behaviours that are universal (see
below). Or by restricting the set of contained values to values for
which the implemented behaviours work correctly. That is: just like any
other kind of programming.
>>Otherwise hard things that junctions make a lot easier:
>>
>> if 0 <= @coefficients < 1 {...}
>
> Ummm... that's an array in numeric context...
Yes. A mistake. I (fairly obviously) meant:
if 0 <= all @coefficients < 1 {...}
>> if ! defined one(@inputs) {...}
>
> I don't get how this could possibly be useful.
That doesn't mean it's not. ;-)
You might use exactly that test to initiate autocomputation of the one
missing value. For example, if you're given volume, pressure, and
temperature values of a gas, but one is undefined, then you might
want to compute it from the others. That test would tell you that you need to
(and that you have enough information to do so).
> 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.
That's simply not true. It is perfectly possible to write an O(n) list
equality test on a list that may include junctions. You simply need an
elementwise equality test that handles junctions correctly. Let's call it
C<same>:
# Junctions same if same type, same number of values, and same values...
multi sub same(Junction $j1, Junction $j2) {
return 0 if $j1.type != $j2.type || $j1.values != $j2.values;
return [&&] same<<($j1.values, $j2.values);
}
# Junctions and non-junctions never the same...
multi sub same(Junction $j, Item $i) is reversible {
return 0;
}
# Non-junctions same if == (or whatever base-case test you prefer)
multi sub same(Item $i1, Item $i2) {
return $i1 == $i2;
}
# List elems equal if each pair of adjacent elements is the same...
sub all_equal(@list) {
return [&&] same<<(@[EMAIL PROTECTED], @list[1...]);
}
> 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!
You can rest assured that I won't try to make one. Because it doesn't
makes *sense* to even talk about an ordered set of junctions. Any more
than it makes sense to talk about an ordered set of vectors, or lists,
or regexes. Will you also be recommending that lists and regexes not be
values???
More seriously, since the ordered set's methods presumably *won't* use
(Item(+)Junction) type arguments, why will this be a problem? The
ordered set will never *see* junctions.
Damian
