Damian Conway writes:
> type KeyExtractor ::= Code(Any) returns Any;
>
> type Comparator ::= Code(Any, Any) returns Int;
>
> type Criterion ::= KeyExtractor
> | Comparator Pair(KeyExtractor, Comparator)
> ;
>
> type Criteria ::= Criterion
> | Array of Criterion
> ;
>
> multi sub *sort(Criteria $by = {$^a cmp $^b}: [EMAIL PROTECTED]) {...}
This is neat stuff. But in order for this to work, we're relying on a
I<very> sophisticated type system. Reminiscent of C++ templates,
actually. And while I love C++ templates for academic challenges, they
don't seem quite what Perl is looking for.
This is pattern matching more than it is type comparison. And Perl's
all about pattern matching. I'm just wondering whether it needs I<two>
pattern archetectures.
If things like this are going to be happening (and thanks, Damian, for
demonstrating exactly how powerful this can be), I'd like types to at
least look more like regexes. Implementation difficulty has not been a
concern of Perl The Language's since the beginning.
Since I'm usually not good at these philosophical posts, I'll show some
examples.
multi sub infix:equals ( (Any) $x, ($1) $y ) { $x eq $y }
multi sub infix:equals ( Any $x, Any $y ) { undef }
Might be a way of nicely comparing apples to apples and rejecting
everything else as unequal. I don't really like the delcaration order
dependency, though. Perhaps:
multi sub infix:equals ({
$x := (Any), $y := ($1) { $x eq $y }
| $x := (Any), $y := (Any) { undef }
});
Which is I<really> starting to look like rules (which is what I wanted).
My summarizing thesis is: if the type system is going to be this rich a
sublanguage, why not make it a formal one? [1]
Luke
[1] Keep in mind that I'm fine with it I<not> becoming a sublanguage,
and relying on user-written code to do this kind of fancy matching. I'm
just saying if we want to make it a rich and powerful pattern matching
system, it ought to look like patterns.
