<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 28, 2018, at 6:49 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">Are you proposing that pairs, lists, Maybe etc all have<span class="Apple-converted-space"> </span><i class="">non-linear</i><span class="Apple-converted-space"> </span>types? </span></div></div></div></blockquote><div><br class=""></div><div>I'm not proposing this -- I was trying to interpret Iavor's paragraph:<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="">Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code. My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).</div></div></blockquote></div><div class=""><div class=""><div class=""><br class=""></div><div class="">My "stable middle ground" comment is that such a design would work: be type-safe, expressive, etc. I don't think it's ergonomic, for the reasons you describe.</div></div></div></div><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">I think we want both (Just :: a -o Maybe a) and (fromJust :: Maybe a -o a); but suppressing the lollipops when printing for the user unless -XLinear is on.</span></div></div></div></blockquote><div><br class=""></div><div>Why fromJust? My understanding is that this proposal comes with no changes to `base`, meaning we would retain the existing fromJust.</div><div><br class=""></div><div>Richard</div></div></div></body></html>