Re: Class names are virtual

2008-04-23 Thread TSa

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


Re: Class names are virtual

2008-04-22 Thread TSa

HaloO,

John M. Dlugosz wrote:
They are mixed!  Perl treats types as first-class objects.  For 
functions, types don't need to be treated specially from other arguments 
as in C++.


Looks like we need a third party ruling on that. Note that the
HOW is the meta class object and the WHAT the prototype object.
None of these *are* types. This is just like the pope is not God
but he is the prime *object* that does Catholic. And of course
it is debatable if God does Catholic ;)


OUTER::C is lexical.  But it sounds like the explanation you are giving 
is the same.


But I find it conceptually clearer to bind a namespace ref
than calling a magic function. It sort of amounts to the same
outcome, though.

I will also have to say something about the usefulness of the
concept of virtual class. Stay tuned.


Regards, TSa.
--

The unavoidable price of reliability is simplicity
  -- C.A.R. Hoare


Re: Class names are virtual

2008-04-22 Thread TSa

HaloO,

John M. Dlugosz wrote:
Larry, you've wanted to have class names used within a class be 
virtual.  With various degrees of conviction across the synopses, you've 
wanted classes defined within a class to be overridable, or all classes 
referenced by a class to be overridable, speculating on whether this is 
do-able.


Let's consider the following code that is a mild rework of John's.

module M
{
class C
{
method mc {...}
}
class D
{
has C $.a; # implies method a is rw :( D: -- C )

method m :( -- C) # P::C in P::E?
{
   my C $b = .new;

   $b = $.a; # type error in E::m?
   $b.mc; # OK for M::C, error for P::C
   $b.pc; # OK for P::C, error for M::C

   return $b;
}
}
}
package P
{
class C
{
   method pc {...}
}
class E is D
{
   # inherits M::D::a and M::D::m
}
}

The point I want to make is that we cannot think of P::C and M::C as
unrelated! There are the following typical uses of C in D:

  1) as the type of the attribute $.a
  2) as return type of m
  3) as type of the local variable $b

Within the body of m I've placed three uses of $b that I think
reveal the type aspect of C in assignment compatibility and in
availability of methods. The only way out I see is that there is
a cross-check of P::C with M::C at CHECK time. Note that the Frog
example in A12 has an inheritance relation between the outer and
the inner classes.

For the record: I don't like the concept of C being virtual in the
same sense as methods are virtual. I think more along the lines of
parametric polymorphism. So D implicitly is 'class D [::C = OUTER::C]'.
This ::C is bound to P::C in 'class E is D'.

Side question: how binary can M be when compiling P? In C++ e.g. the
template code of D has to be available. Are there interface files in
Perl 6?


Regards, TSa.
--

The unavoidable price of reliability is simplicity
  -- C.A.R. Hoare


Re: Class names are virtual

2008-04-22 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


The point I want to make is that we cannot think of P::C and M::C as
unrelated! There are the following typical uses of C in D:

  1) as the type of the attribute $.a
  2) as return type of m
  3) as type of the local variable $b

Within the body of m I've placed three uses of $b that I think
reveal the type aspect of C in assignment compatibility and in
availability of methods. The only way out I see is that there is
a cross-check of P::C with M::C at CHECK time. Note that the Frog
example in A12 has an inheritance relation between the outer and
the inner classes.

I agree, the issues with ② changing but ① not changing in E is mitigated 
if the new C is a subclass of the old C.  I believe that extending 
hierarchies in parallel was Larry's germ.



For the record: I don't like the concept of C being virtual in the
same sense as methods are virtual. I think more along the lines of
parametric polymorphism. So D implicitly is 'class D [::C = OUTER::C]'.
This ::C is bound to P::C in 'class E is D'.
Attributes are frozen into the base class and don't override the way 
members do.  That is why virtual class names don't apply to them.


If you wanted to define D as generic, you could do that too!  In fact, 
if we had a pseudo-package that meant ignore the current meaning of C 
and find the C that would be found if this one didn't exist that was 
not bound at compile time, then you could get the same effect by using 
the default argument to D all the time and not worrying about it being 
generic.


I think this is what you are getting at.  Maybe it could just work that 
way?  There are subtle differences; Since D[C1] is a different type than 
D[C2] it means that E would not be a subclass of D, and in fact D would 
vary depending on what was in scope every time it is used not just when 
it is used as a base class!


Since subtyping will not be tied to subclassing like C++, Java, etc. 
then maybe that is not a problem, and maybe the concept (virtual class 
names) needs to be rethought in light of these other developments.





Side question: how binary can M be when compiling P? In C++ e.g. the
template code of D has to be available. Are there interface files in
Perl 6?



My intention is to always specify things such that M can be compiled, 
with introspection information available (e.g. you can use 
M::($variable) ). 


--John



Re: Class names are virtual

2008-04-22 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:
They are mixed!  Perl treats types as first-class objects.  For 
functions, types don't need to be treated specially from other 
arguments as in C++.


Looks like we need a third party ruling on that. Note that the
HOW is the meta class object and the WHAT the prototype object.
None of these *are* types. This is just like the pope is not God
but he is the prime *object* that does Catholic. And of course
it is debatable if God does Catholic ;)

I think I see what you are getting at, but it was not really clear from 
your reply.
Using Dog in an expression (rather than a declaration) returns an 
undefined protoobject of type Dog.  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.  
We want


  my Dog $x;
  my Type $t;

  $x = Dog;
  $t = ::Dog;

to both work.  Maybe

  $t = Dog;

will work as well, by suitable supertypes and/or conversions of the type 
of the protoobject.
Or maybe it's the other way around: Dog is of type Class, which has an 
implicit coersion to Dog defined on it that returns the protoobject.





OUTER::C is lexical.  But it sounds like the explanation you are 
giving is the same.


But I find it conceptually clearer to bind a namespace ref
than calling a magic function. It sort of amounts to the same
outcome, though.
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.



Maybe Larry will wade in.

--John


Re: Class names are virtual

2008-04-22 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


For functions, types don't need to be treated specially from other 
arguments

as in C++.


Could you give an example of what you mean in C++ and how Perl differs
from that?



In C++, types are not first-class objects.  You can't pass a type as a 
normal parameter because there is no such thing.


So type parameters are treated differently with their own syntax:

   fooC,D(x,y,z);

In Perl, you can simply pass

   foo(::C, ::D, x, y, z);

because types are first-class objects.  You can define parameters that 
have a Type type, and use their value to create objects of that type, 
and even annotate declarations.


--John


Re: Class names are virtual

2008-04-21 Thread TSa

HaloO,

John M. Dlugosz wrote:

I hope you have a few minutes to look it over.


I started to think it through. There are two quick remarks.

In
 module M
 {
class C { ... }
class D
{
# lexical region where C refers to M::C
method m1 () { my C $x; my Int $y; ... }
class C { ... }
# lexical region where C refers to D::C
method m2 () { my C $x; ... }
}
 }

I would make the use of C in m1 of D an error because otherwise
the scope D is split into two at the point where D::C is defined.
In other words D::C is not the innermost definition everywhere in
D. This is a serious source of subtle errors. If this is what you
want than write M::C in m1. Scopes should be one-dimensional along
the lines of inner versus outer. An additional dimension before
versus after should be used only for error checking. That is in m1
C is parsed provisionally as M::C and this fails when D::C is seen
later.

Second, I don't like the concept of a virtual method that returns
a type. That horribly mixes type level and value level. From the
namespace POV we have M::D::foo and P::E::foo bound to the same
implementation. In both cases C is OUTER::C. The magic should
happen when an invocation of foo is created. That is the moment when
the scope of OUTER::C can be bound by 'my C $b' through $x and $y
respectively.


Regards, TSa.
--

The unavoidable price of reliability is simplicity
  -- C.A.R. Hoare


Re: Class names are virtual

2008-04-21 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:



Second, I don't like the concept of a virtual method that returns
a type. That horribly mixes type level and value level. From the


They are mixed!  Perl treats types as first-class objects.  For 
functions, types don't need to be treated specially from other arguments 
as in C++.


OUTER::C is lexical.  But it sounds like the explanation you are giving 
is the same.