On Tue, May 03, 2005 at 05:06:15PM +0800, Autrijus Tang wrote:
: With the recent discussion on type sigils, and the fact that Pugs
: is moving toward the OO core, I'd like to inquire how the following
: statements evaluate (or not):
:
: # Compile time type arithmetic?
: ::Dual ::= ::Str | ::Num;
Yes, but I think that is the same as
our ::Dual ::= ::Str | ::Num;
which sets Dual in the current package, not in *.
Also, the :: is of course optional on the existing types.
: $*Dual ::= ::Str | ::Num;
Probably works, assuming types autoenreference in scalar context so that
$*Single ::= Str;
is equivalent to
$*Single ::= \Str;
: # Run time type arithmetic?
: my ::dual := ::Str | ::Num;
Yes.
: # Type Instantiation?
: sub apply (&fun<::a> returns ::b, ::a $arg) returns ::b {
: &fun($arg);
: }
The first parameter would be &fun:(::a) these days, but yes.
(Stylistically, I'd leave the & off the call.)
: # Does Role live in the same namespace as Types/Classes/Modules/Packages?
: my ::role = role { ... };
Yes, though in this case that namespace is a subset of the lexical
namespace.
: # Can class take type parameters like Roles cna?
: class Pet[Type $petfood] {
: method feed (::($petfood) $food) {...}
: }
Don't think so. I'd like to keep generics/parametric types associated
with roles if possible, so that we know exactly when they are composed
into a class. If that means we have to write a few classes that do
nothing but wrap around a role, I think it's probably worth it.
: # Single colon as tuple composer?
: my $Triple ::= :(Bool, Int, Str);
: my $TripleTuple ::= :($Triple, $Triple);
: my &pair_with_int ::= -> Type ::t { :(::t, Int) };
I think of it as the signature composer. Does Haskell call them
tuples? That word tends to mean any immutable list in other circles,
though I suppose :(4, 2, "foo") could be construed as a type whose
values are constrained to single values. But it makes :(int $x)
terribly ambiguous if it's an evaluative context. (Which is why
we wanted :() in the first place, to avoid such evaluation.)
Larry
