HaloO,
Jonathan Lang wrote:
OK. My main dog in this race is the idea of defining new roles
through the concepts of the intersection or difference between
existing roles (even the union was thrown in there mainly for the sake
of completion), with the consequent extension of the type system in
HaloO,
Jonathan Lang wrote:
OK. My main dog in this race is the idea of defining new roles
through the concepts of the intersection or difference between
existing roles
Note that you should not call these 'intersection type' because
this term is used for the union of role interfaces. That is
TSa schreef:
A(|)B produces a subtype of A and B, and that A()B
produces a supertype
Are you sure? I see as limiting; sub and | as enlarging;
super.
To me, is connected to multiplication (and inproduct, statistics,
fuzzy logic), and | to addition (and outproduct).
$ perl -we 'printf
HaloO,
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A()B
produces a supertype
Are you sure?
Very sure ;)
In record subtyping a record is a mapping of labels to types.
In Perl 6 speak this is what a package does. One record type
is a subytpe if it
TSa writes:
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A()B produces a
supertype
Are you sure?
Very sure ;)
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, with some people expecting
HaloO,
Smylers wrote:
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, with some people expecting it to work
exactly opposite to how it does.
So the mere fact that there are two sets involved rules out the
set operators as well?
It doesn't
Smylers wrote:
TSa writes:
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A()B produces a
supertype
Are you sure?
Very sure ;)
In which case that provides a handy example supporting Larry's
suggestion that this is confusing, with some people
TSa [EMAIL PROTECTED] wrote:
I strongly agree. Having a language that allows supertying has novelty.
But I think that union is not there for completion but as integral part
when it comes to defining a type lattice which I still believe is the
most practical approach to typing. This includes
HaloO,
Jonathan Lang wrote:
If we make a point of highlighting the set operations perspective
You know that there are two sets involved. So which one do you mean?
and avoiding traditional type theory
terminology (which, as Larry pointed out and TSa demonstrated, is very
much inside out
TSa wrote:
Jonathan Lang wrote:
OK. My main dog in this race is the idea of defining new roles
through the concepts of the intersection or difference between
existing roles
Note that you should not call these 'intersection type' because
this term is used for the union of role interfaces.
HaloO,
Jonathan Lang wrote:
BTW, are the ASCII equivalents spelled (), () and (in)?
I'd hope that they'd be something like '()', '()', and 'in'; only
use parentheses when neccessary. Likewise, I'd want the relative
complement operator to be '-', not '(-)'.
Funny. I would have hoped that
Jonathan Lang schreef:
() and (|) would actually reflect your intuition regarding the
capabilities of the result, in that a role arrived at by means of ()
would provide fewer options than the individual roles used to create
it, while a role arrived at by means of (|) would provide more
HaloO,
Jonathan Lang wrote:
my @array = (0,1,2); # Array of Int
@array[3] = three; # Array of Int()Str
Actually, these would be something along the lines of Array of Int
and Array of (Int, Int, Int, Str), respectively. That is, each of
@array[0..2] would be of type Int, while @array[3]
HaloO,
Jonathan Lang wrote:
role R3 does A B { ... }
R3.does(A) # false: R3 can't neccessarily do everything that A can.
A.does(R3) # false: A can't neccessarily do everything that R3 can.
That last one should be true. Role R3 contains the things that A and B
have in common. Hence
TSa wrote:
Jonathan Lang wrote:
role R3 does A B { ... }
R3.does(A) # false: R3 can't neccessarily do everything that A can.
A.does(R3) # false: A can't neccessarily do everything that R3 can.
That last one should be true. Role R3 contains the things that A and B
have in common.
HaloO,
Jonathan Lang wrote:
In short, R3 isn't neccessarily a subset of A; it's a superset of A
B. In a partial ordering graph, there's no reliable ordering between
R3 and A.
The standard syntax for creating roles can't reliably produce a subset
of an existing role, because it always allows
HaloO,
I wrote:
In fact if we decide to specify a role combination syntax then it
should be the same everywhere. That means in a signature A|B would
require a more specific type and pure A or B wouldn't be admissible.
To get the old meaning of | you have to write AB or perhaps the
juxtaposition
HaloO,
I wrote:
Yes, but I was conjecturing that the additions to AB are pushed
down to A and B such that their intension sets remain strict supersets
of AB.
Think of the Complex example that might read
role Complex does Num !Comparable
{
method im { return 0; }
method re {
TSa wrote:
Jonathan Lang wrote:
In short, R3 isn't neccessarily a subset of A; it's a superset of A
B. In a partial ordering graph, there's no reliable ordering between
R3 and A.
The standard syntax for creating roles can't reliably produce a subset
of an existing role, because it always
TSa wrote:
Here is yet another idea to go with the two lattice operations:
/\ meet also: infimum, intersection, glb (greatest lower bound)
\/ join also: supremum, union,lub (least upper bound)
I have to admit: if it turns out that '' and '|' can't be used for
'intersection'
On Fri, Oct 20, 2006 at 09:10:12AM -0700, Jonathan Lang wrote:
: TSa wrote:
: Here is yet another idea to go with the two lattice operations:
:
:/\ meet also: infimum, intersection, glb (greatest lower bound)
:\/ join also: supremum, union,lub (least upper bound)
:
: I have
21 matches
Mail list logo
