<div dir="ltr"><div>Perhaps this is not what you had in mind, but we could write a signature like</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> {-# LANGUAGE KindSignatures #-}<br> signature Mystery where<br> import Data.Kind<br> import Control.Monad<br> data MysteryMonad :: Type -> Type<br> instance Functor MysteryMonad<br> instance Applicative MysteryMonad<br> instance Monad MysteryMonad<br> instance PrimMonad MysteryMonad</blockquote><div><br></div><div>that reused the existing PrimMonad class. Code could depend on that signature without being tied to a concrete monad (this would make the package that has the code "indefinite"). Once we compiled the indefinite code against an actual implementation, it would be optimized as if we had used concrete types from the beginning.</div><div><br></div><div>One problem with this solution is that it leaves out ST. If we wanted to make it work with ST, one possible hack would be to define the signature like this</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> data MysteryMonad :: Type -> Type -> Type<br> instance Functor (MysteryMonad s)<br> instance Applicative (MysteryMonad s)<br> instance Monad (MysteryMonad s)<br> instance PrimMonad (MysteryMonad s)</blockquote><div><br></div><div>And then use some kind of newtype adapter with a phantom type for non-ST monads:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">module Mystery where </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">type MysteryMonad = W IO<br>newtype W m a b = W (m b) deriving newtype (Functor, Applicative, Monad)</blockquote><div><br></div><div>But perhaps it would complicate things too much.</div><div> </div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 11, 2021 at 2:08 PM <<a href="mailto:haskell-cafe-request@haskell.org">haskell-cafe-request@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send Haskell-Cafe mailing list submissions to<br>
<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:haskell-cafe-request@haskell.org" target="_blank">haskell-cafe-request@haskell.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:haskell-cafe-owner@haskell.org" target="_blank">haskell-cafe-owner@haskell.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Haskell-Cafe digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Backpack: polymorphic instantation? (Jaro Reinders)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 11 Sep 2021 11:58:26 +0200<br>
From: Jaro Reinders <<a href="mailto:jaro.reinders@gmail.com" target="_blank">jaro.reinders@gmail.com</a>><br>
To: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br>
Subject: [Haskell-cafe] Backpack: polymorphic instantation?<br>
Message-ID: <<a href="mailto:3fb19986-f998-61c7-8c56-482b1647e2eb@gmail.com" target="_blank">3fb19986-f998-61c7-8c56-482b1647e2eb@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
I'm playing around with backpack, trying to rewrite existing libraries. My end <br>
goal is to see if Backpack could improve the primitive library. Right now, the <br>
primitive library (in my opinion) relies too heavily on specialization of its <br>
type classes, so I think Backpack could help. However, I seem to be running <br>
into a limitation. I am wondering if it is a fundamental limitation, if perhaps <br>
there is a workaround, or if Backpack could be improved to support this use-case.<br>
<br>
Instead of primitive, I will take the simpler example: semigroup, which also <br>
shows this limitation. Let's convert the Semigroup class to a backpack signature:<br>
<br>
unit indef where<br>
signature Semigroup where<br>
import Prelude hiding ((<>))<br>
data T<br>
(<>) :: T -> T -> T<br>
<br>
The problem is how to implement this signature with the type of polymorphic <br>
lists. It is easy to implement it for concrete lists like strings:<br>
<br>
unit string where<br>
module Semigroup where<br>
import Prelude hiding ((<>))<br>
type T = String<br>
(<>) :: T -> T -> T<br>
(<>) = (++)<br>
<br>
It is also possible to implement it in terms of another signature:<br>
<br>
unit list where<br>
signature Elem where<br>
data A<br>
<br>
module Semigroup where<br>
import Prelude hiding ((<>))<br>
import Elem<br>
type T = [A]<br>
(<>) :: T -> T -> T<br>
(<>) = (++)<br>
<br>
This is still problematic, because it is annoying that this new type A needs to <br>
be instantiated each time you want to use it. However, even more importantly, <br>
if I want to translate the 'PrimMonad' class to a Backpack signature then the <br>
'ST s' instance needs a polymorphic type variable 's', which cannot be made <br>
concrete.<br>
<br>
And do note that I want the monad to be concrete for performance reasons, but <br>
the 's' parameter doesn't have to be concrete, because it is a phantom <br>
parameter anyway. And for lists making the 'a' parameter concrete also would <br>
not improve performance as far as I know.<br>
<br>
One possible way to fix this is to add a type variable in the 'Semigroup' <br>
signature, but then I think it becomes impossible to write the 'String' <br>
instance and sometimes you need more than one new type variable such as with <br>
the 'ReaderT r (ST s)' instance of 'PrimMonad'.<br>
<br>
In OCaml you can still kind of work around this problem by creating local <br>
instances inside functions. That trick still allows you to write a polymorphic <br>
concatenation function using a monoid signature (taken from [1]):<br>
<br>
let concat (type a) xs =<br>
let module MU = MonoidUtils (ListMonoid(struct type t = a end)) in<br>
MU.concat xs;;<br>
<br>
So, I'm wondering if it would be possible to "generalise" over indefinite <br>
Backpack types such as 'A' in the 'Elem' signature above or if we can at least <br>
implement something which enables the same trick that you can use in OCaml.<br>
<br>
Thanks,<br>
<br>
Jaro<br>
<br>
[1] <a href="https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html" rel="noreferrer" target="_blank">https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html</a><br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Haskell-Cafe Digest, Vol 217, Issue 10<br>
*********************************************<br>
</blockquote></div></div>