[Haskell-cafe] Language extension proposal: aspects

[Theodore Lief Gannon]

Namespace notation might not be optimal, because it's not clear at a glance
that this is an aspect and not a regular qualified import of a type (an
important distinction if you have multiple versions of the same type
imported, e.g. Bytestring). Why not make it look like type application
instead? Modifying your example:

allEven :: (Integral a) => [a] -> Bool at A_All_

And for that matter, I'd rather not be forced to write a signature (what if
I want to use this in a where clause?) So... does this break anything?

allEven = foldMap at A_All_ even

Which means, for this invocation of foldMap, instances within A_All_
are in effect for all of its constraints. You could chain multiple @'s
together so long as they don't produce any relevant overlapping
instances.

To avoid surprises, they shouldn't propagate -- when foldMap invokes
even, it sees the default Monoid instance for Bool (i.e. none). If it
were also a function that needs a Monoid, you'd need another @.
There's potential for boilerplate here. Falling back to doing it in
the type signature could force propagation? I'm not sure it's ever a
safe idea, though.


On Sat, May 6, 2017 at 1:55 PM, MarLinn <monkleyon at gmail.com> wrote:

> On 2017-05-06 21:37, Dmitry Olshansky wrote:
>
>> How does compiler can infer a type for "allEven = foldMap even" ?
>>
>> Something like
>> allEven :: (Monoid (aspect Bool), Integral a) => [a] -> Bool ?
>>
>
> I hadn't thought about inference actually. But even if the compiler
> inferred a type, it would still fail with a missing constraint. So I don't
> strongly care what the implied constraint is, as long as the error message
> is comprehensible. Maybe it could mention aspects in the future, but that's
> not even necessary. So basically the inferred type would just be
>
>         allEven :: (Monoid Bool, Integral a) => [a] -> Bool
>
> The compiler would just know "I need a Monoid instance for Bool!" as it
> does right now. And just as now, it knows where to look – the only
> difference is that with my proposal that place to look has a different name.
>
> Should all Bool's in function body have the same aspects?
>>
>
> Yes, if the aspect comes from a type signature. If the type signature is
> local, it would be local to its region of application. For example:
>
> ---
> module Test where
>
>     import qualified Data.Bool under (Default, Data.Aspect.Bool.All) as
> A_All_ (Bool)
>     import qualified Data.Bool under (Default, Data.Aspect.Bool.Any) as
> A_Any_ (Bool)
>
>     test2 :: (Integral a) => [a] -> Bool
>     test2 xs = (foldMap even xs :: A_All_.Bool) == not (foldMap odd xs ::
> A_Any_.Bool)
>
> The type is imported twice with different names and under different
> aspects. The local type signatures use these names to define which are the
> right instances.
>
> An alternative would be something like
>
>     test2 :: (Integral a) => [a] -> Bool
>     test2 xs = (foldMap even xs :: (Bool under A_All_)) == not (foldMap
> odd xs :: (Bool under A_Any_))
>
> which would make the aspect-nature clearer. But I didn't want to introduce
> even more syntax, especially as the naming scheme is already enough.
>
> Was that clarifying?
>
> I have to say, your questions did make me ponder how much of my proposal
> would already be possible by exploiting type families. I'm not sure yet,
> but I'll think about it. So thanks!
>
>
> Cheers,
> MarLinn
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170506/97e087f0/attachment.html>