Thanks for the feedback!
aspect Data.Aspect.Bool.Any where
instance Monoid Bool where mempty = False mappend True _ = True mappend False b = b how would this interact with superclasses
class Monoid m => Newclass m
Aspects wouldn't care about superclasses directly. That's still the role of the instance declaration. But aspects – like normal modules – would be able to choose under which aspects to import their own dependencies. So in this way they would be able to "choose" their line of heritage. Of course if you import an aspect, you would also get all that heritage.
As I understand the proposal, you got default instances.
Mostly as a convenience and for backwards compatibility, but yes, in the form of the Default aspect. In fact every single instance we have now would initially be a "default instance" in the new model, by implicitly being in that aspect. It would probably be a good idea to move at least some of them to dedicated aspects though. The class system itself would be unchanged, including the defaulting and inheritance rules. But you would be able to drop the default instances by dropping the default aspect. You just would have to be aware that you'd be dropping all the default instances for the whole hierarchy of this constructor.
But how do you extend with the alternative instance? by you examples with foldMap you would need to extend the data type with the aspect you mean to do it, well that is exactly what newtypes are! thus far I don't see any benefits of making it less explicit.
I would have to implement the second instance in a second aspect, just without all the wrapping we do now. So yes, on first sight my proposed solution really offers little functionality that newtypes don't. But I claim the results already look much cleaner and should lead to more readable code. I also expect there might be bigger benefits to come from the separation of concerns and when you're able to just inherit big chunks of theory. Imagine that instead of injecting lots of Sum and getSum deep into a structure you could just add one type signature via proxy. Imagine extending the Sum aspect to elaborate on what the concept of "summation" really means instead of being stuck in the Num hierarchy. Why have All/Any and Sum/Product separately when they really describe the same basic concept? Why have Data.Ord.Down and Control.Applicative.Backwards when the underlying idea is exactly the same? Also, it's such a simple idea but how many would even think to look for these newtypes here? And do you know if there is a similar newtype for Foldable? Where would you look? If there is one aspect, just look into this aspect, done. That's what I really want aspects to describe: mathematical concepts that we use over and over, independently from the concrete types. Hope I was able to answer some questions? Cheers, MarLinn