HaloO,
John M. Dlugosz wrote:
Using Dog in an expression (rather than a declaration) returns an
undefined protoobject of type Dog.
Yeah, an avatar.
But we already know that this is
supposed to work:
my ::Alias ::= Dog;
but maybe the RHS of ::= (if not :=) has its own special parsing rules.
Historical comment: I proposed to change ?? :: to ?? // and it became
?? !!. This was to reserve :: for abstraction. BTW, is :: the ASCII
circumscription of U+2237?
In the same regime I would like to snatch ::= from it's current meaning
of the compile time version of := to always mean abstraction aliasing.
Fortunately I'm also preaching the unmixability of types and values---
the "no half gods principle". This sort of preserves the idea of ::=
acting at compile time only. In particular you can't use ::= twice in a
scope with the same lhs. I.e. the single assignment principle at work.
The my in 'my ::Alias ::= Dog' looks redundant if not outright stupid.
What would 'our ::Alias ::= Dog' mean? And what's the use of 'my
::*Alias ::= Dog'? Note that there is immense power in unlimited
namespace access that must be restrictable with some form of sandboxing.
We want
I guess this we doesn't include me.
my Dog $x;
my Type $t;
Note that this means you are constraining the values of $x and $t to
the predeclared types Dog and Type respectively. This does not make $t a
type variable.
$x = Dog;
This is OK, and assigns the Dog proto to $x. This is a value
transfer. But the protoobject was in there before because this
is what the my put there. Like a dog box that already smells
like dog even when brand new.
$t = ::Dog;
This should be a syntax error, or at best the same as above under
the 'variable as view' paradigm. But it should never mean to alias
Type and Dog in the surrounding scope. This would be ::Type ::= Dog
and result in a redeclaration error of Type because the Type in
'my Type $t' was provisionally parsed as OUTER::Type.
You could never use $t in a type position anyway:
my $t $y; # syntax error
I wonder how & "variables" fare in that respect. I would expect
single assignment semantics from them as well. At least as far as
the usage as unsigiled var is concerned:
foo(); # provisionally OUTER::foo
my &foo := get_some_code_ref(); # OK?
&foo(); # sigil not optional because that violates OUTER::foo
foo(); # still OUTER::foo?
In general I expect :: and & to compete for the same slot in a
namespace's scope. But there is a sigiled slot &foo, of course.
A sigiled slot ::foo makes no sense to me.
BTW, since ::= obviously has a left and right side and it does name
binding we consequentially have lnames and rnames just as we have
lvalues and rvalues. Same with ltypes and rtypes, lkinds and rkinds
and other things.
Functions have a name and signature. The former is the nominal type
the latter the structural type. E.g.
sub trigon ( Num --> Num) {...}
sub sin (Num --> Num) does trigon {...}
sub cos (Num --> Num) does trigon {...}
sub foo (Num --> Num) {...}
Structurally they are the same. But &foo.does(trigon) is false.
OTOH, you can have
sub sin (Complex --> Complex) {...}
nominally sin, that is &sin.does(trigon) is true independent
of signature. An item variable constraint to the latter declaration
reads:
my sin:(Complex --> Complex) $sin;
That is you can bind or assign any implementation that nominally does
sin and structurally does :(Complex --> Complex). If you want to
dispatch on the signature you need sin to be a multi, of course. A
generic implementation might require its parameters to do Field[::N]
and return a Field[N], i.e. it requires Complex <: Field[Complex] and
Num <: Field[Num] in F-bounded polymorphism or CBP (constraint bounded
polymorphism) that subsumes FBP. See
<http://www.cs.washington.edu/research/projects/cecil/www/Papers/vass-thesis.html>
Captures are also structural types. In the end this means the
Perl 6 type system is---contrary to the synopsis---structural and
nominal.
This makes more sense after reading your later message. You want
implicit generics, with the attendant specialization phase that provides
a point where these bindings can occur, rather than the virtual name
idea from the original Apocalypse.
I sort of want the functionality of a full-blown type system as part
of the runtime environment. That is there is a type computation going
on in parallel to a value computation. The meta object system is largely
part of the value system. The things the type system does at runtime is
checking assignments, checking bindings, selecting dispatch targets and
instanciating parametric types.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
