<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Thanks Tom,<br>
<br>
After the last email I sent, I was left thinking that the way in which this could be a problem was some generic Functor function that had intermediate values that could violate the constraints, but such that it's type signature respected it, but I didn't think
much else on it. I think your example is exactly this: you use the getLine fmap inside the function, which is fine for a general Functor, but produces a temporary no-Ord functor, while the overall function preserves the signature.<br>
<br>
And yeah, the only possible way to go around this would be to actually have additional "notes" on the signature of functions which said what it internally needed, which not only is horrendous but I believe crashes strongly against a lot of other things we do
in Haskell (or any similar language for that matter)<br>
<br>
So, yeah, I understand the issue.<br>
<br>
To respond to your last comment. First, I realize this is not what you are saying, but please someone do let me know if at some point my posts feel excessive or out of place. I have a strong issue with both often not being able to tell the social context very
well and also being very insecure about making a fool out of myself for that reason. Second, my situation is practical (my research is not on programming languages), but I cannot deny I like an elegant solution like most other people here probably do, so I
often go a bit further than strictly necessary out of curiosity. This is not the case in this instance, though. This is still giving me problems and I still haven't found a satisfactory workaround for my particular problem, no matter how "dirty" it would be.
I think I'll figure it out eventually, though. It seems to be just a matter of instantiating enough type variables to exactly what I want to use them for.<br>
<br>
I do see your suggestion, one that I had considered myself; but it's more useful coming from someone who seems to know what they're doing better than me, so that if I end up deciding to avoid type classes for certain complex things I am more secure it's not
just me being dumb, but rather that there be dragons that I don't want to fight. However, a practical issue with avoiding type classes tends to be that function signatures tend to become larger, larger and larger, making the code very very cluttered. So I
think that's where the art comes, in finding the balance between those two things. A lot of my complex issues come from a sort-of obsession with making code as modular as possible. This is a long topic and I know it's not a "solvable" problem, but I try to
push things as far as I can in that regard (within reason, I try).<br>
<br>
Thanks again, this does respond everything I doubted about this particular issue.<br>
Juan.<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Haskell-Cafe <haskell-cafe-bounces@haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017@jaguarpaw.co.uk><br>
<b>Sent:</b> 23 February 2021 19:27<br>
<b>To:</b> haskell-cafe@haskell.org <haskell-cafe@haskell.org><br>
<b>Subject:</b> Re: [Haskell-cafe] DatatypeContexts / alternative</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">This email was sent to you by someone outside the University.<br>
You should only click on links or attachments if you are certain that the email is genuine and the content is safe.<br>
<br>
On Tue, Feb 23, 2021 at 06:37:06PM +0000, CASANOVA Juan wrote:<br>
> Yes I realize that, but what I am expecting, I guess, is for the<br>
> type checker to tell me (or anyone who tried to use it) that Foo (IO<br>
> String) makes no sense, because Foo is always applied to something<br>
> with Ord. That the very concept of the type Foo (IO String) itself<br>
> does not type check.<br>
><br>
> I realize the answer might be that this is impossible with current<br>
> Haskell, but then a) Is there any fundamental reason why it is<br>
> impossible<br>
<br>
Yes, there's a fundamental reason. Neither you nor the compiler can<br>
possibly know when invalid Foos (i.e. those whose parameter isn't Ord)<br>
are constructed inside a function polymorphic in a Functor . Let's<br>
extend my example.<br>
<br>
mapToUnit :: Functor f => f a -> f ()<br>
mapToUnit = fmap (const ()) . fmap (const getLine)<br>
<br>
whatShouldItDo :: Foo ()<br>
whatShouldItDo = mapToUnit (Foo (Data.Map.singleton () ()))<br>
<br>
Do you agree that whatShouldItDo is well typed? If not, why not?<br>
If so, how should it behave when evaluated? The implementation of<br>
mapToUnit , combined with your Functor instance says that fromList<br>
must be run on [(getLine, getLine)] . But this is impossible!<br>
<br>
Accepting that whatShouldItDo is well typed implies that you must<br>
accept that your Functor instance for Foo cannot work. (I don't<br>
believe any instance can work if it is law-abiding but I don't know of<br>
a proof.)<br>
<br>
There is a cottage industry of trying to work around this problem.<br>
See, for example [1]. I have never seen a satisfactory solution.<br>
<br>
Based on your posts here you are frequently running into the limits of<br>
type class based programming in Haskell. If your purpose is practical<br>
I strongly advise you to stay away from type classes for anything<br>
non-trivial. Stick to the value level. Your life will be much<br>
easier. If your purpose is research into type classes, or general<br>
interest, then good luck and enjoy!<br>
<br>
Tom<br>
<br>
<br>
[1] <a href="https://jeltsch.wordpress.com/2015/09/03/constrained-monads/">https://jeltsch.wordpress.com/2015/09/03/constrained-monads/</a><br>
<br>
<br>
> ________________________________<br>
> From: Haskell-Cafe <haskell-cafe-bounces@haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017@jaguarpaw.co.uk><br>
> Sent: 23 February 2021 18:29<br>
> To: haskell-cafe@haskell.org <haskell-cafe@haskell.org><br>
> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative<br>
><br>
> This email was sent to you by someone outside the University.<br>
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.<br>
><br>
> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:<br>
> > module DatatypeContextsExample where<br>
> ><br>
> > import Data.Map<br>
> > import Data.Bifunctor<br>
> ><br>
> > data Foo t = Foo (Map t t)<br>
> ><br>
> > instance Functor Foo where<br>
> > fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))<br>
> ><br>
> > This does not compile, because I am using toList and fromList, which<br>
> > require (Ord t). But I cannot really have Foo be a functor in this<br>
> > way without it. The thing is, every time I am going to use it, t is<br>
> > actually going to be Ord. But how do I tell Haskell to have this<br>
> > constraint?<br>
><br>
> You say that every time you are going to use it t is actually going to<br>
> be Ord, but how does the compiler know that when it comes to type<br>
> check fmap? After all, somewhere else you could write<br>
><br>
> fmap (const getLine) :: Foo t -> Foo (IO String)<br>
><br>
> and IO String is certainly not Ord.<br>
_______________________________________________<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">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br>
</div>
</span></font></div>
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
</body>
</html>