HaloO Ingo,
you wrote:
> I wondered if it would be useful/good/nice if the syntax for
> specifying role parameters would be the same as the standard
> subroutine signature syntax (minus the colon, which
> separates the parameters which do account to the long name
> of the role from the ones which don't).
Hmm, first you exclude the colon, then you use it the example??
I for my part hope that roles are---among other things---parametric
types. This means that in the brackets one should find type variables,
value variables and possibly recursive constraints. E.g.
role Ordered[::Type does Ordered[Type]]
{
multi method infix:{'<='} ( T $x, T $y ) returns bit
{
...
}
multi method infix:{'>'} ( T $x, T $y ) returns bit
{
return not $x <= $y;
}
}
class Num does Ordered[Num] { ... }
class Str does Ordered[Str] { ... }
expresses that instances of these classes can be only ordered amongst
themselfs and their subtypes. E.g. with
class Int is Num {...}
the following is allowed:
my Int $i = 3;
my Num $n = 3.14;
if $i < $n {...}
but
my Str $s = "foo";
if $s < $n {...} # type error
This type error can be alleviated with implementing
class Scalar does Ordered[Num|Str] {...}
Actually the class might be needed only as namespace containing
the implementation of &infix:{'<='}:(Num|Str,Num|Str: --> bit).
OTOH it could implement caching of conversion results or some such.
--
$TSa =:= all( none( @Larry ), one( @p6l ))
Thread Previous
|
Thread Next