<div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">I am retired but still on the list so I read it sometimes :). (feel free to unsubscribe me)</div><div dir="auto"><br></div><div dir="auto">But since I was not sure where else to comment, I thought I'd chime in here to say that I also find this pretty confusing.</div><div dir="auto"><br></div><div dir="auto">My assumption/intuition is that 'data' should always introduce a lifted type, and 'newtype' should have the same liftedness as its definition. I would much prefer that if we wanted to have some sort of unified 'data' we should have a separate construct for it (e.g., like the proposed 'data unlifted')</div><div dir="auto"><br></div><div dir="auto">Iavor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 18, 2021, 11:33 Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm bothered both by distance, and the hidden-ness of Wombat, and (most fundamentally) by the fact that the data type declaration itself is not self-describing. Usually if I look at a type signature for a function and don't really understand it, I can rely on the type checker to ensure that it's only called in well-typed ways. I can also just look at the code for the function, and infer a type that is either the same or more general.<br>
<br>
Not so here. I boggled that we can write<br>
data IntU a b = IntU Int<br>
and not know whether it is lifted or not. That's about *semantics* and runtime behaviour, not mere static acceptance/rejection!<br>
<br>
I suppose my base principle is:<br>
* If GHC can infer a type for a declaration<br>
* Then it's ok to omit or ignore the type/kind signature<br>
<br>
That is, signatures (a) are needed when inference is Too Hard (b) restrict polymorphism. But they should not (c) change semantics.<br>
<br>
Now I know that because of dark corners of the language, defaulting etc, the signature of a function *can* affect its semantics, but it is rare and very much a dark corner -- it's a wart. But this is right at the heart of what every data declaration means. I don't want to use one small wart to justify a much larger wartier wart.<br>
<br>
I wish I had realised this at the time. Apologies for that.<br>
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank" rel="noreferrer">eric@seidel.io</a>><br>
| Sent: 18 August 2021 03:57<br>
| To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" rel="noreferrer">simonpj@microsoft.com</a>>; ghc-steering-<br>
| <a href="mailto:committee@haskell.org" target="_blank" rel="noreferrer">committee@haskell.org</a>; Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" target="_blank" rel="noreferrer">sgraf1337@gmail.com</a>><br>
| Subject: Re: [ghc-steering-committee] Unlifted data types<br>
| <br>
| I think the distance between the `type IntU` and `data IntU` is the crux of<br>
| the issue. If we were forced to keep the signature and declaration together,<br>
| i.e.<br>
| <br>
| ```<br>
| type IntU :: Bool -> Wombat<br>
| data IntU a b = IntU Int<br>
| ```<br>
| <br>
| I wouldn't be bothered by the distance from the definition of `Wombat`.<br>
| <br>
| If I'm reading this code, and I already know what Wombat is, there's no<br>
| problem. If I *don't* know what Wombat is, then I need to look up its<br>
| definition anyway to make sense of IntU.<br>
| <br>
| I've never been particularly fond of Haskell's tolerance for separating<br>
| signatures and definitions. It has some practical uses -- notably in<br>
| combination with -XCPP it makes it easy to ensure signatures are consistent<br>
| across CPP branches -- but in general I think distance between signature and<br>
| definition is a smell.<br>
| <br>
| On Wed, Aug 11, 2021, at 03:48, Simon Peyton Jones via ghc-steering-<br>
| committee wrote:<br>
| ><br>
| > I have just posted<br>
| ><br>
| <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co</a><br>
| m%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-<br>
| 896626642&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C9bd05c205b5d4757d4cd0<br>
| 8d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474023194%<br>
| 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi<br>
| LCJXVCI6Mn0%3D%7C3000&sdata=sr6XzIgF5CSnLyol8jSfjHToJpD86Q7bPHnKkaMjMgI%<br>
| 3D&reserved=0> this, about unlifted data types. Yikes!<br>
| > Simon<br>
| ><br>
| > *In accepted proposal #265 on Unlifted Datatypes<br>
| > <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit</a><br>
| > <a href="http://hub.com" rel="noreferrer noreferrer" target="_blank">hub.com</a>%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=04%7C01%<br>
| > 7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988b<br>
| > f86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWF<br>
| > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M<br>
| > n0%3D%7C3000&sdata=OWlj9RxqQfTBZcjp1QE5AUSSvnG%2By3wbuXL2VbqEGpw%3<br>
| > D&reserved=0>* I have just realised that in this accepted, and<br>
| > implemented proposal we have done something entirely new. Consider<br>
| > this (from<br>
| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl</a><br>
| > <a href="http://ab.haskell.org" rel="noreferrer noreferrer" target="_blank">ab.haskell.org</a>%2Fghc%2Fghc%2F-%2Fissues%2F20204&data=04%7C01%7Csim<br>
| > onpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C9bd05c205b5d4757d4cd08d961f3ea95%7C72f988bf86f1<br>
| > 41af91ab2d7cd011db47%7C1%7C0%7C637648524474033189%7CUnknown%7CTWFpbGZs<br>
| > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D<br>
| > %7C3000&sdata=9SNn4GSIs%2Bd40SBQCEpYfYh7hO73XLoXY%2BWE2uuTg0k%3D&a<br>
| > mp;reserved=0)<br>
| ><br>
| > `type IntU :: Bool -> Wombat` ` ` `...LOTS OF CODE...` ` ` `data IntU<br>
| > a b = IntU Int` ` ` `...MORE CODE...` ` ` `type Wombat =Type -> TYPE<br>
| > UnliftedRep` The kind signature for `IntU` *completely changes the<br>
| > semantics of the *`*data IntU*`* declaration*, and yet can be separate<br>
| > from it. That is<br>
| > new: generally, signatures can restrict the applicability of<br>
| > something, but *don't change its semantics*. (Yes, with overlapping<br>
| > instances, certainly incoherent instances, you could change semantics,<br>
| > but the general principal holds.)<br>
| ><br>
| > Even if it is adjacent, the fact that it's unlifted is quite subtle...<br>
| > you have to look to the right of the arrows, and then through the<br>
| > distant (and perhaps imported) type synonym `Wombat`.<br>
| ><br>
| > I'm not very happy with a distant kind signature having such a<br>
| > profound effect on the semantics of the data type. Indeed in my<br>
| > comment above<br>
| > <<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit</a><br>
| > <a href="http://hub.com" rel="noreferrer noreferrer" target="_blank">hub.com</a>%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265%23issuecomment-52<br>
| > 5705557&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C9bd05c205b5d4757d<br>
| > 4cd08d961f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524<br>
| > 474033189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi<br>
| > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fB257%2Flsx8ucSnW%2Fgc<br>
| > %2FPP50rVz4e2MJJCZgmc%2FB08jo%3D&reserved=0> I suggested a keyword<br>
| ><br>
| > `data unlifted IntU a b = IntU Int`<br>
| > to signal that it's an *unlifted* data type. But then I went AWOL and<br>
| > didn't pursue the matter. I don't know why I was so negligent.<br>
| ><br>
| > So this post is to ask: does anyone else think this is bizarre? I'm<br>
| > inclined to make a proposal to add the keyword, but I thought I'd test<br>
| > the waters first.<br>
| ><br>
| ><br>
| > _______________________________________________<br>
| > ghc-steering-committee mailing list<br>
| > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" rel="noreferrer noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>
| > .<a href="http://haskell.org" rel="noreferrer noreferrer" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a<br>
| > mp;data=04%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer noreferrer" target="_blank">40microsoft.com</a>%7C9bd05c205b5d4757d4cd08d961<br>
| > f3ea95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637648524474033189<br>
| > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I<br>
| > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rwunJpephHqcWKNE%2F0IpMPS21mWSL<br>
| > uyYr3V%2FVs6hfCo%3D&reserved=0<br>
| ><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" rel="noreferrer">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>