Re: Syntax for specifying role parameters
[EMAIL PROTECTED] wrote:
I don't think that a role has a long and a short name. This is
because they aren't subject to MMD. I think of them more as
beeing expanded like C++ templates even though the actual mechanism
will be much more sophisticated. Actually I think of them as F-bounds
as well ;)
Uhm, but C++ templates are subject to (compile-time) MMD, once you
specialise them. In other words,
role Something[Int $num] {...}
role Something[String $num] {...}
could just as well work. :)
Miro
Re: Syntax for specifying role parameters
Miroslav Silovic wrote:
Uhm, but C++ templates are subject to (compile-time) MMD, once you
specialise them. In other words,
role Something[Int $num] {...}
role Something[String $num] {...}
Hmm, C++ has no free floating templates. They always template a
class/struct or a function. The Perl6 equivalent is to have e.g.
role Template[ ::Type ] {...}
multi sub foo( Template[Int] $x ) {...}
multi sub foo( Template[Str] $x ) {...}
And since roles are not instanciable the above actually
needs a class that does Template.
Questions for @Larry:
would making ::Type optional look as follows:
role Template[ ?::Type = Str ] {...}
or refering to the class that Template is composed into:
role Template[ ?::Type = $?CLASS ] {...}
I think having the full flexibility of required, optional and
named parameters plus their slurpy versions, etc. is enough.
What does a long/short name distinction add in expressiveness?
--
TSa (Thomas SandlaÃ)
Re: Syntax for specifying role parameters
Ingo Blechschmidt wrote: I meant: The colon should still act as the delimiter between the params which account to the long name of the role and those which don't, but otherwise the syntax should be the same as the standard subroutine signature syntax, allowing optional params, etc. I don't think that a role has a long and a short name. This is because they aren't subject to MMD. I think of them more as beeing expanded like C++ templates even though the actual mechanism will be much more sophisticated. Actually I think of them as F-bounds as well ;) s/T/::Type/? Ohh, sorry. Yes, or the other way round. Should be consistent. -- TSa (Thomas SandlaÃ)
Re: Syntax for specifying role parameters
Hi,
"TSa (Thomas SandlaÃ)" wrote:
> 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 meant: The colon should still act as the delimiter between the params
which account to the long name of the role and those which don't, but
otherwise the syntax should be the same as the standard subroutine
signature syntax, allowing optional params, etc.
> 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
s/T/::Type/?
[...]
--Ingo
--
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD | understand recursion.
Athlon!|
Re: Syntax for specifying role parameters
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 ))
Syntax for specifying role parameters
Hi,
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).
E.g.:
role MyRole[
Str $required_param,
Bool ?$optional_param_defaulting_to_undef,
: # beginning of the parameters which don't account to the
# long name of the role
Num ?$opt_param_defaulting_to_42 = 42,
Any ?$evil_var = $CALLER::_,
] {...}
$x does MyRole["abc", 1];
# or
$x does MyRole[required_param => "bar", evil_var => 23];
# etc.
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over.
generation on a dual AMD | The computers won.
Athlon!| -- Eduard Bloch
