On Mon, Nov 07, 2005 at 01:05:16PM +0100, TSa wrote:
: With the introduction of kind capture variables ^T we could complety
: drop the subtype special form. As you pointed out the adding of constraints
: happens with the where clause anyway. Thus we return to the usage of the
: compile time name assignment form
:
: ::Blahh ::= ::Fasel where {...}
:
: where the :: in all cases means working on the MIR (Meta Information
: Repository) which is the world of names (In Russian, Mir (Мир) means
: "peace," and connotes "community." --- cited from Wikipedia).
Except that a type declarator can remove the need for all those extra ::
markers. (Actually, the ::Fasel can be presumably written Fasel if
Fasel is already declared, so the only strangeness is on the left.
We could hack identifier-left-of ::= like we did identifier-left-of =>,
or we could turn ::= into more of a general alias macro idea. But I think
people generally like declarators out to the left for readability.)
: Question: shouldn't there be a natural 1 to 1 relation of ::T and ^T
: or globally ::*T and ^*T where the former is the name and the latter
: the kind represented by T? Of course scoping applies and there are
: anonymous things that can be captured into ^T vars at runtime.
Yes, that's basically how I see it. ::T is the literal form, ^T is the
free form, but both map to package T in some scope or other.
: If the answer is 'yes' as I expect, I wonder if the compiler has to restrict
: the usage of ::= to scopes which don't depend on runtime evaluations like
:
: if $x < 10 { ::*Surprise ::= ::*FunnyType; say 'did it'; }
:
: Or should these be extracted out, making the above mean
:
: ::*Surprise ::= ::*FunnyType; # or further out if necessary
:
: if $x < 10 { say 'did it'; }
To me it's similar to
my $x = 1 if $y;
which should probably just be disallowed or warned about under strict.
On the other hand, the declarations in a class file are also contingent
on the class being used, so those declarations are also in a conditional
context. So maybe we should just declare such things to be erroneous.
: >: Question: does a subtype declaration work only on package-like things
: >: which are addressed with a :: sigil? Or does your 'potentially
: >: contravariant' mean that arrow types can be constraint or aliased, as
: >: well?
: >:
: >: subtype TakesInt of Sub where { .sig =:= :(Int --> Any) };
: >:
: >: my TakesInt &foo;
: >:
: >: foo('a string'); # type error
: >
: >Hmm, I would read that as declaring that &foo *returns* a TakesInt,
: >not that &foo *is* a TakesInt. Just as
: >
: > my TakesInt @bar;
: >
: >declares an array of individual TakesInt elements.
:
: This is not too bad because then the & sigil is naturally associated
: with the :( --> ) arrow type syntax and the forms can be mixed only
: to the extent of signature aliasing:
:
: ::Takes3Ints ::= :(Int,Int,Int --> Any);
:
: my &foo:(Takes3Ints);
I'd say that has to be something like:
my &foo:(Takes3Ints:);
or maybe one of
my &foo:(Takes3Ints \!);
my &foo:(\Takes3Ints);
my &foo\(Takes3Ints);
since Takes3Ints is the implementation and/or arglist type.
Otherwise how do you distinguish
my &foo:(Takes3Ints);
my &foo:(Int, Int, Int);
: How does arrow typing apply to the three data sigils $, @ and %?
: Compare:
:
: my $foo:(Int); # non-referential value type
: my $foo:(-->Int); # same? Or perhaps means anonymous ref/link/alias?
: my $foo:(Ref-->Int) # explicit reference? same as 'is ref' trait?
: my $foo:(Item: -->Int) # tied container
:
: Which is the default when the Int is used in the type slot of the
: declaration?
:
: my Int $foo;
That means
my $foo:(-->Int);
: Could this be used to define the key type of hashes?
:
: my %foo:(Blahh-->Any);
:
: And shape of arrays
:
: my @foo:(Int,Int,Int-->Any);
:
: where the Int or subtypes of it are enforced and Any defaulted.
Certainly. I wouldn't mind getting rid of the "shape" property.
: Thus this could just be
:
: my @foo:(!,!,!);
Yeah, though that doesn't mean you can't write @foo[1] and get a :(!,!)
out of it.
: The covariant invocant/container types are of course
:
: my $item :(Item: --> Any);
: my @array:(Array: Int --> Any);
: my %hash :(Hash: Key --> Any);
:
: The & sigils have a free signature and ^ vars obviously have no signature
: other than pure type ;)
Works for me. As with & sigs, we might be able to lose the colon in
a declarative context:
my $item(Item: --> Any);
my @array(Array: Int --> Any);
my %hash(Hash: Key --> Any);
The colon would still be required in an rvalue context. But the extension
of that to subs seems to be:
my &sub(Sub: \$args)
Hmm, does that mean that a method actually looks like this?
my &meth(Method: $self: \$args)
I also wonder about hybrid hash/arrays:
my %harry(HashArray: Key^Int --> Any);
It would be nice to generalize this sufficiently to be able to declare
polymorphic objects resembling match objects:
my $matchobj(Poly: Key^Int^Notthere --> Any);
Or maybe that should be:
my $matchobj\(Highlander);
:-)
Larry
