<p dir="ltr">The difficulty and inconvenience of using Forall and the fact that it is very far from standard Haskell make it unsuitable for some purposes. I believe it can probably lead to some efficiency issues as well, since the constraint has to be instantiated manually at each type; perhaps GHC can optimize that away. It would be fantastic if the language could expand to allow such constraints natively, but for now it seems that manually writing multiple classes is often the best approach.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 1, 2016 5:24 PM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Let's just pause and consider what is already available on hackage today for these situations:</div><div><br></div><div><br></div><div><br></div><div>In my <font face="monospace, monospace">constraints</font> package I have a class named `Lifting`, which provides.<br></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">class Lifting p f where<br> lifting :: p a :- p (f a)</font></div><div><br><div><span style="background-color:rgb(255,255,255)">L</span>ifting Eq, Lifting Monad, Lifting Semigroup, Lifting (MonadReader e), etc. are then able to be handled all uniformly.</div><div><br></div><div>It is, alas, somewhat annoying to use, as you need to use `\\ lifting` with a scoped type variable signature to get the instance in scope<br></div><div><br></div><div>The currrent Eq1 is a somewhat more powerful claim though, since you can supply the equality for its argument without needing functoriality in f. This is both good and bad. It means you can't just write `instance Eq1 f` and let default methods take over, but it does mean Eq1 f works in more situations if you put in the work or use generics to generate it automatically.</div><div><br></div><div><div><a href="http://hackage.haskell.org/package/constraints-0.8/docs/Data-Constraint-Lifting.html" target="_blank">http://hackage.haskell.org/<wbr>package/constraints-0.8/docs/<wbr>Data-Constraint-Lifting.html</a><br></div></div><div><br></div><div><br></div><div><br></div><div>For the rank-2 situation, I also have `Forall` and `ForallF` which provides the ability to talk about the quantified form.<br></div><div><br></div><div>ForallF Eq f is defined by a fancy skolem type family trick and comes with</div><font face="monospace, monospace"><br>instF :: forall p f a. ForallF p f :- p (f a)</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">This covers the rank-2 situation today pretty well, even if you have to use `\\ instF` or what have you to get the instance in scope.</font></div><div><br></div><div><br></div><div><br></div><div>I don't however, have something in a "mainstream" package for that third form mentioned above, the 'Functor'-like form, but I do have classes in semgroupoids for Alt, Plus, etc. covering the particular semigroup/monoid-like cases. <br></div><div><br></div><div><br></div><div><br></div><div>Finally, going very far off the beaten and well-supported path, in `hask`, I have code for talking about entailment in the category of constraints, but like the above two tricks, it requires the user to explicitly bring the instance into scope from an `Eq a |- Eq (f a)` constraint or the like, and the more general form of `|-` lifts into not just Constraint, but k -> Constraint, and combines with Lim functor to provide quantified entailment. This doesn't compromise the thinness of the category of constraints. I'd love to see compiler support for this, eliminating the need for the \\ nonsense above, but it'd be a fair bit of work!</div><div><div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 2:10 PM, Mario Blažević <span dir="ltr"><<a href="mailto:blamario@ciktel.net" target="_blank">blamario@ciktel.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">CC-ing the Café on class naming...<span><br>
<br>
On 2016-10-01 04:07 AM, Edward Kmett wrote:<br>
</span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm somewhat weakly against these, simply because they haven't seen<br>
broad adoption in the wild in any of the attempts to introduce them<br>
elsewhere, and they don't quite fit the naming convention of the other<br>
Foo1 classes in Data.Functor.Classes<br>
<br>
Eq1 f says more or less that Eq a => Eq (f a).<br>
<br>
Semigroup1 in your proposal makes a stronger claim. Semgiroup1 f is<br>
saying forall a. (f a) is a semigroup parametrically. Both of these<br>
constructions could be useful, but they ARE different constructions.<br>
</blockquote>
<br></span><span>
The standard fully parametric classes like Functor and Monad have no suffix at all. It makes sense to reserve the suffix "1" for non-parametric lifting classes. Can you suggest a different naming scheme for parametric classes of a higher order?<br>
<br>
I'm also guilty of abusing the suffix "1", at least provisionally, but these are different beasts yet again:<br>
<br>
-- | Equivalent of 'Functor' for rank 2 data types<br>
class Functor1 g where<br>
fmap1 :: (forall a. p a -> q a) -> g p -> g q<br>
<br>
<a href="https://github.com/blamario/grampa/blob/master/Text/Grampa/Classes.hs" rel="noreferrer" target="_blank">https://github.com/blamario/gr<wbr>ampa/blob/master/Text/Grampa/C<wbr>lasses.hs</a><br>
<br>
What would be a proper suffix here? I guess Functor2 would make sense, for a rank-2 type?<br>
<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><span>
If folks had actually been using, say, the Plus and Alt classes from<br>
semigroupoids or the like more or less at all pretty much anywhere, I<br>
could maybe argue towards bringing them up towards base, but I've seen<br>
almost zero adoption of the ideas over multiple years -- and these<br>
represent yet _another_ point in the design space where we talk about<br>
semigroupal and monoidal structures where f is a Functor instead. =/<br>
<br>
Many points in the design space, and little demonstrated will for<br>
adoption seems to steers me to think that the community isn't ready to<br>
pick one and enshrine it some place central yet.<br>
<br>
Overall, -1.<br>
<br>
-Edward<br>
<br>
On Fri, Sep 30, 2016 at 7:25 PM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a><br></span><span>
<mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>><wbr>> wrote:<br>
<br>
I've been playing around with the idea of writing Haskell 2010<br>
type classes for finite sequences and non-empty sequences,<br>
somewhat similar to Michael Snoyman's Sequence class in<br>
mono-traversable. These are naturally based on Monoid1 and<br>
Semigroup1, which I think belong in base.<br>
<br>
class Semigroup1 f where<br>
(<<>>) :: f a -> f a -> f a<br>
class Semigroup1 f => Monoid1 f where<br>
mempty1 :: f a<br>
<br>
Then I can write<br>
<br>
class (Monoid1 t, Traversable t) => Sequence t where<br>
singleton :: a -> t a<br>
-- and other less-critical methods<br>
<br>
class (Semigroup1 t, Traversable1 t) => NESequence where<br>
singleton1 :: a -> t a<br>
-- etc.<br>
<br>
I can, of course, just write my own, but I don't think I'm the<br>
only one using such.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br></span><span>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
<<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-b<wbr>in/mailman/listinfo/libraries</a>><br>
<br>
<br>
<br>
<br></span><span>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</span></blockquote>
<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.</blockquote></div><br></div>
<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-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>