[Haskell-cafe] Language extension proposal: aspects

[MarLinn]

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