Like others, I'm a little confused by the purpose of your post, but one word of warning that may upset your assertion: Perl 6 roles aren't stateless

From Synopsis 12:

Roles may have attributes:

    role Pet {
        has $.collar = Collar.new(Tag.new);
        method id () { return $.collar.tag }
        method lose_collar () { undefine $.collar }
    }
[download]

Of course, whatever state they have becomes a part of the instance into which they are composed (Can roles have Class attributes?), which in a way is a little similar to the way Functors acquire transient access to the values they are applied to, but still that state persists.

Given my previously declared (and sometimes comprehensively proven!) lack of Haskell-fu, I'm loath to draw conclusions, but I think that somewhat queers the pitch as far as comparisons between Functors and Roles are concerned.

Roles don't -have- attributes. Roles can -provide- attributes to the classes they are composed into. If you have a Cat and Dog, each of which does Pet, then if you have a $cat instance and a $dog instance, the $.collar attribute of each is separate. They aren't shared in any sense. Therefore, Perl6 roles -are- stateless in that the role itself doesn't have any state. (Which makes sense given that you cannot instantiate a role.)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Roles don't -have- attributes.

Hm. The quote was directly from Synopsis 12, so as far as the wording is concerned, you need to argue with the authors.

As far as the semantics are concerned, I did go on to say: "Of course, whatever state they have becomes a part of the instance into which they are composed", so I think we're in tune there.

But, as I also said, and regardless of whether the state is has'd by the Role, or provided by it, that state exists and is presumably usually affected by the Role and persists beyond the invocation of whatever methods the role also provides, so there is no sense in which it can reasonably be described as stateless.

If my limited understanding of ML's Functors means that they are like (my also limited understanding of) Haskell's Typeclasses, then the term composed in the sense you are using it: "composed into"; and that same term in the sense the OP used it: "more easily composable units."; are entirely different things.

With the former composing both operations and state, and the latter performing operations on values only (hence stateless). Quite different beasts. The best discussion I have located upon the difference is this.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

.oO(...sits back, once more, to await flames:-)

Except that roles/traits compose and abstract/virtual classes still just inherit. The composition is the real win with traits/roles, without it they would be nothing more then ... uhm... abstract/virtual classes ;)

-stvn

I think I must be missing the point stvn, I thought a class (in whatever language) was the composition of methods and/or data to model a behaviour.
A user level that continues to overstate my experience :-))

Traits (and Roles) are very much like Functors in functional programming.

If you mean Functors in the SML/OCaml sense, then yes. If you mean Functors like in Haskell, then not really, they are closer to Typeclasses in Haskell.

Yes - I had SML in mind. I've updated the root node. Thanks.