Luke Palmer wrote:
>  When you say:
> 
>     role Foo superdoes Bar superdoes Baz {...}
> 
>  You are saying Foo = Bar (+) Baz (+) ...;  # union of Bar, Baz, and
>  the following spec

For the record, I think that "superdoes" should be spelled "done_by".

>  It may seem like that should be Foo = (Bar (+) Baz) (*) ...;  (indeed,
>  I thought that for a while and then corrected myself).  But if
>  anything that is a Bar is a Foo, anything that is a Baz is a Foo, and
>  some other stuff is also a Foo (this being the important case), then
>  that should clearly be a union.

Note that in your usage of the set operations, "Bar (+) Baz" requires
"Bar.^methods (*) Baz.^methods" and "Bar (*) Baz" requires
"Bar.^methods (+) Baz.^methods".  This means that the spec that
follows would act to further limit the methods that end up in Foo,
such that only methods that appear in Bar, Baz, _and_ the spec would
end up in Foo.  (As a secondary issue, your definition of "Bar (+)
Baz" strikes me as counterintuitive; but maybe that's because I tend
to view roles as sets of methods.)

>  Things work a little differently for required methods.  When a
>  superrole requires a method be implemented, we (the language
>  designers) have a choice to make: it is illegal if the superrole
>  requires a method that the subroles don't implement or don't
>  themselves require, or it simply adds the new method to the required
>  list of the subroles which don't implement it.  I'm inclined to say
>  the former, even though it seems a little more brittle.

I agree with your inclination; but bear in mind that this would make
it illegal to define Complex as a superrole of Num, since Complex has
methods that Num doesn't have.  Also bear in mind that if Complex is a
superrole of Num, a parameter that asks for a Num should by all rights
reject a Complex that's handed to it.

I agree with the idea of being able to define superroles (for lack of
a better name); my problems lie entirely with the proposed
implementation of the concept.  I'll reiterate my alternative:

When using set operations with roles, treat the roles as sets of
methods.  Each set operation defines an anonymous role with the
resulting set of methods; as with any other anonymous thing, it can be
bound to a name.  In addition, a few of the set operations establish
.does() relationships between the new role and the roles used to
create it:

   role C ::= A (+) B # C.does(A) and C.does(B)
   role D::= A (*) B # A.does(D) and B.does(D)
   role E ::= A (-) B # A.does(E)

and so on.  In particular, these lines would be equivalent to

   role C does A does B {}
   role D done_by A done_by B {}
   role E done_by A except B {}

...with the added benefit that you don't have any confusion as to how
"does", "done_by", "except", etc. interact with each other or with the
new spec.  Further, grouping of set operations makes it easy to define
"staged composition":

   (A (+) B) (*) C

would mean "compose an anonymous role as the union of A and B, and
then compose an anonymous role as the intersection of that and C".
Among other things, this would allow method definitions in C to
override those of the anonymous union.

--
Jonathan "Dataweaver" Lang