4. The proposal that we have multiple versions of modules loaded at the same time scares me. I cannot help but think that it is an inherently fragile thing to attempt, particularly if someone does anything dynamic. Problems comes in many flavours, and I'm not sure which bothers me most. Here is a sample.

* How can the feature help if developers have not specified versions for dependencies?

* How do you handle versioning of proxied modules?

* When will bugs go away?

* What code am I REALLY running?

* Where's my data?

* What about C libraries?

* Feeling bloated?

When I first heard about the idea of trying to support having multiple versions of software on your system, I thought that it was a fundamentally broken idea. No, I don't want the added complexity when I think that it will fail, and complicate my life in the process. That opinion hasn't improved with time...

1. Having read the discussion of how roles will be implemented with multiple inheritance, how well will the role/trait stuff play with people declaring the current inheritance model?

Got it..maybe. When you describe here that roles are actually done with multiple inheritance, you are actually walking about multiple inheritance being used when you WALKMETH, so that even though you think that you are only inheriting along a chain, some links of the chain of inheritance may choose to search a little hidden sub-bush. (Particularly if your Role declared that it is some other class.)

Or something like that.

But it doesn't matter whether I understand this. I just hope that the implementor gets the joke...

I hope so too, considering it's the implementor that made up the joke in the first place. If anything, the joke was on me. Which is the other part that makes it really, really funny... :-)

3. I'd like to understand the proposed aliasing mechanism better than I do. I understand the need (particularly when cooperating across languages), but I'd like to understand how it will be done.

Certainly there are lots of issues to deal with here. Even what you name your exceptions changes across languages...

I'm not entirely sure that I understand what you mean by "allomorphic references". However the first design that comes to my mind is that Perl 6 should define what it looks like to refer directly to something in another language, and then there should be tools built to offer a translation service, translating the one language into another. If no translation layer exists, then things like errors are pretty much opaque to Perl. If a translation layer exists, then it handles things however you would like.

A thought: the translation layers should not just map classes, but should be able to add/detect useful metadata. For instance in translating Perl errors into Ruby or Python, it may be good to allow a Perl type to translate into a Ruby Class, and a Ruby Class to translate into a Perl Class with some extra metadata tagged on it (so that it falls into a type that would be translated back). This piece of complexity allows you to do as reasonable a job as is realistically possible in translating between 2 class hierarchies that divided things up in fundamentally incompatible ways.

Yes, this kind of approach would make those interfaces substantially more complex. But I think that the complexity is necessary.

A tangential thought that this discussion of translation brings to mind. I think that it is important for the Perl world to plan on some "best practices" for handling internationalization. (Documentation, error messages, etc.) The current CPAN works great..if you're willing to say that all programmers must speak English fluently. But I'm convinced that many people with scripting problems do not speak English as a first language, and I'd like to think that Perl will attempt to address their problems.

Definition of alomorph:

A variant phonological representation of a morpheme; "the 
final sounds of `bets' and `beds' and `horses' and `oxen' 
are allomorphs of the English plural morpheme"
[download]

UPDATE:

For those without ancient languages... greek and latin roots. Basically morph is shape, allo is "different" or "another".

Another definition for allomorph seems a bit closer to Larry's reply: "An allomorph is one of two or more complementary morphs which manifest a morpheme in its different phonological or morphological environments."

So, I guess in the computer context, an allomorph is an object that manifests differently depending on the context.

2. My major concern about any mix-in kind of design (including inheritance and roles) is that people can wind up having methods available and have no idea where the method came from. I'm hoping that there will be a limited number of very useful traits and roles that are built in (or at least widely used) and people don't go about building too many of their own. That will let me amortize the cost of learning them over a lot of usage. This is not, however, fundamentally a language design issue but an education one.

$method.meta.getattributes doesn't list source class/role and version metadata but it could be included.

This non-transparent method source also worried me. The combination of multiple inheritence, roles, traits, runtime role-things, multiple dispatch (including subtypes and signature distance), dispatcher/traversal options and the autoloading possibilities together make interpreting a method call potentially quite tricky. It seems like the composability and flattening of the Traits Paper has been lost.

I have to remind myself that while the explanation has to be exhaustive, the cognitive load during programming should in fact be lighter.

It seems like the composability and flattening of the Traits Paper has been lost.

You must have missed this statement: "The .getmethods method has a selector parameter that lets you specify whether you want to see a flattened or hierarchical view, whether you're interested in private methods, and so forth."

But yes, it would be nice if the flat view could also give you the pedigree of the methods.

I agree wholeheartedly with your reservation regarding versioning.

Any library, module or class exports two things. It's interface, and it's implementation. Whilst the implementation can go through versions, the interface cannot.

Once defined, even before implementation, an interface becomes fixed. If the interface later varies, it becomes an new interface. Anything written to comply with the old interface will need to be adapted to use the new one, no matter how small the change.

You can dress the new version's name up by applying a version number to the old name, but that simply means that the name of the new interface looks superficialy, but misleadingly similar to the old one.

Even if the new interface is a proper superset of the old interface, it still means that code using either are forced into making loadtime or runtime tests to determine which version of the interface they have access to. In the case of existing code, connecting to the new version, if it remains unmodified, there is the possibility of conflict between new features of that new interface and existing features or extensions added by the pre-existing caller.

In the case of new code that doesn't now whether it will have the new or old version of the interface at runtime, it must then add code to test for teh availability of the new features and either fail if it doesn;t have them r supply alternatives.