[Haskell-cafe] Language extension proposal: aspects
monkleyon at gmail.com
Sat May 6 20:01:22 UTC 2017
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?
More information about the Haskell-Cafe