On 2008-Oct-22, at 10:03 am, TSa wrote:
David Green wrote:
One thing I would like signatures to be able to do, though, is
assign parameters by type. Much like a rule can look for
identifiable objects like a <block> or <ident>, it would be very
useful to look for parameters by their type or class rather than by
name (or position).
Note that types have a fundamentally different task in a signature
than name and position have. The latter are for binding arguments to
parameters. The types however are for selection of dispatch target.
Names do that too; I think both names and types should be available
for both binding and dispatching, depending on what's more natural in
a given context. Sometimes we think in terms of names (I'm going to
Fred's place), sometimes in terms of types (I'm going to the grocery
store). (And some types are names (Dad)!)
In single dispatch it is very important if your dispatch is handled
in the Nail or Hammer class. In multi dispatch one can still
distinguish &action:(Hammer,Nail) from &action:(Nail,Hammer). There
is the following syntax to define two sigs for the same body
multi method action (Hammer $hammer, Nail $nail)
|(Nail $nail, Hammer $hammer)
Sneaky, I hadn't thought of doing it that way. Of course, a mere five
objects give you an unwieldy 120 possibilities, so some syntactic
relief is called for. Perhaps something like an & to indicate that
the parameters are not sequential:
sub foo ($posn0, $posn1, Bar $type1 & Baz $type2 & Bat $type3, :
$named1, :$named2)
-David
