MultipleGenericRoots

So after playing with generics for a good while, I've discovered the following two things:

Capping a generic by using a 'dg' is potentially annoying to other users/yourself because it prevents the use of a symbol in other semantic domains. Eg, 'add' has been co-opted by the collections API and capped, so if you want to use add to something that does not descend from a collection, you're screwed. Although arguments can be made about efficiency, we'll assume the because the multiple parallel trees that form are so far apart that it should be reasonably easy to eliminate the overhead in dispatch (by pointing into the appropriate sub-tree of the decision tree, for example.)

Not capping a generic can lead to a haphazard forest of tiny trees. A capped generic provides incentive to have a well-designed class hierarchy. If you are not constrained by having to belong to a certain tree, you could very well have gobs of classes all over the place, and thanks to multi-method dispatch (with a tree rooted at <any>), you can effectively kludge around this, but I have an inkling that this will lead to extreme ugliness, as well as potential failure of dispatch to correctly determine the correct generic to call once you start using multiple inheritance to cobble it all together.

Therefore I suggest: Multiple Generic Roots!

In other words, 'dg' performs a union with the previous tree-caps. I think this creates a nice fusion of both worlds by requiring you to clearly mark the territory that you are going to build in. That way you get the protection from accidentally 'building in the wilderness', while not screwing over any other use of the symbol's name.

(Note that because generics live at the binding level there is currently no way to fuse the contents of two generics together, so you can't work around the collection 'add' issue other than by renaming 'add' to 'col-add' or something like that. I don't believe that module:binding is sufficiently robust either.)

-- AndrewSutherland