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 @ar
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:
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 th
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:
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 fr
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 com
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, wit
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 re
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
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 ha
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 -w
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
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
HaloO,
Larry Wall wrote:
> I now think it's a bad idea to overload | or & to do type construction,
Is it then a god idea to overload the set operations? At least the
type constructions are set theoretic on the intension set of the
roles.
> especially since the tendency is to define them backwar
Larry Wall wrote:
Anyway, I think the type constructors need to avoid overloading the
logic operators. Perl 6 is an operator-rich language because that
contributes to long-term clarity despite the short-term confusion.
OK. My main dog in this race is the idea of defining new roles
through the
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 ha
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'
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
HaloO,
I wrote:
Yes, but I was conjecturing that the additions to A&B are pushed
down to A and B such that their intension sets remain strict supersets
of A&B.
Think of the Complex example that might read
role Complex does Num & !Comparable
{
method im { return 0; }
method re
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 A&B or perhaps the
juxtaposition
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
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:
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 e
23 matches
Mail list logo