<div dir="ltr"><div>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:</div><div><pre style="white-space:pre-wrap">allEven :: (Integral a) => [a] -> Bool@A_All_</pre></div><div>And for that matter, I'd rather not be forced to write a signature (what if I want to use this in a <font face="monospace, monospace">where</font> clause?) So... does this break anything?<br></div><div><pre style="white-space:pre-wrap">allEven = foldMap@A_All_ even</pre><pre style="white-space:pre-wrap"><font face="arial, helvetica, sans-serif">Which means, for this invocation of </font><font face="monospace, monospace">foldMap</font><font face="arial, helvetica, sans-serif">, instances within </font><font face="monospace, monospace">A_All_</font><font face="arial, helvetica, sans-serif"> are in effect for all of its constraints. You could chain multiple </font><font face="monospace, monospace">@</font><font face="arial, helvetica, sans-serif">'s together so long as they don't produce any relevant overlapping instances.</font><br></pre><pre style="white-space:pre-wrap"><font face="arial, helvetica, sans-serif">To avoid surprises, they shouldn't propagate -- when </font><font face="monospace, monospace">foldMap</font><font face="arial, helvetica, sans-serif"> invokes </font><font face="monospace, monospace">even</font><font face="arial, helvetica, sans-serif">, it sees the default </font><font face="monospace, monospace">Monoid</font><font face="arial, helvetica, sans-serif"> instance for </font><font face="monospace, monospace">Bool</font><font face="arial, helvetica, sans-serif"> (i.e. none). If it were also a function that needs a </font><font face="monospace, monospace">Monoid</font><font face="arial, helvetica, sans-serif">, you'd need another </font><font face="monospace, monospace">@</font><font face="arial, helvetica, sans-serif">. 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.</font></pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 6, 2017 at 1:55 PM, MarLinn <span dir="ltr"><<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-05-06 21:37, Dmitry Olshansky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How does compiler can infer a type for "allEven = foldMap even" ?<br>
<br>
Something like<br>
allEven :: (Monoid (aspect Bool), Integral a) => [a] -> Bool ?<br>
</blockquote>
<br></span>
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<br>
<br>
        allEven :: (Monoid Bool, Integral a) => [a] -> Bool<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should all Bool's in function body have the same aspects?<br>
</blockquote>
<br></span>
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:<span class=""><br>
<br>
---<br>
module Test where<br>
<br>
    import qualified Data.Bool under (Default, Data.Aspect.Bool.All) as A_All_ (Bool)<br>
    import qualified Data.Bool under (Default, Data.Aspect.Bool.Any) as A_Any_ (Bool)<br>
<br></span>
    test2 :: (Integral a) => [a] -> Bool<br>
    test2 xs = (foldMap even xs :: A_All_.Bool) == not (foldMap odd xs :: A_Any_.Bool)<br>
<br>
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.<br>
<br>
An alternative would be something like<br>
<br>
    test2 :: (Integral a) => [a] -> Bool<br>
    test2 xs = (foldMap even xs :: (Bool under A_All_)) == not (foldMap odd xs :: (Bool under A_Any_))<br>
<br>
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.<br>
<br>
Was that clarifying?<br>
<br>
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!<div class="HOEnZb"><div class="h5"><br>
<br>
Cheers,<br>
MarLinn<br>
<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br></div>