<div><div><br></div></div><div><div class="gmail_quote"><div dir="auto">On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <<a href="mailto:redirect@vodafone.co.nz">redirect@vodafone.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>indeed .. and we can reasonably say "lets deal with the bandaid in one go by cleaning it up in the next standard"<div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Thanks Carter/Brandon, the reason for asking how we should go about the discussion was exactly: where/how are we going to maximise the chance of finding out what code is out there, and how disruptive any 'clean up' might be?</div><div dir="auto"><br></div><div dir="auto">Ghc has occasionally made breaking releases (not saying that's what we want to do), usually with some advance warning/deprecation period. And generally the Haskell community has accommodated that with understanding of the decision, to fix their code.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>so what would the next gen look like?</div><div><br></div><div>eg: fresh variables get the usual implicit forall at the front of the type, and everything else either needs an explicit quantifier OR it refers to the outer implicit quantified variable?</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I wanted to avoid discussing 'next gen' in possibly-obscure/write-only mailing lists; and preferably get the discussion where posterity can see the reasoning/examination of options.</div><div dir="auto"><br></div><div dir="auto">"fresh variables get the usual implicit forall" is what happens now. (It's just that the User Guide explains it really badly -- I'm trying to fix that separately <a href="https://ghc.haskell.org/trac/ghc/ticket/15146">https://ghc.haskell.org/trac/ghc/ticket/15146</a> .) If the outer variable(s) are not explicitly forall-quantified, then even same-named variables count as fresh. IOW merely putting a `forall` can change the meaning of a program -- that's what causes the most confusion (judging by SO).</div><div dir="auto"><br></div><div dir="auto">The exception is variables bound in a pattern signature for an existentially-quantified data constructor: they *must* be fresh. This is hard for a reader to follow because the pattern signature with data constructor looks the same whether or not the constructor is existentially-quantified. What's worse a constructor might have a mix of existential and universal variables.</div><div dir="auto"><br></div><div dir="auto">AntC</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery <span><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><span>On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <span><<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">So the explanation I've seen for the current design is it was deliberately idiosyncratic, to minimise any disruption to existing code. Then I'm asking whether any of that code is still around? If not/if it's been re-factored to use ScopedTypeVariables, then any tweak to the design could have a freer hand.</pre></div></blockquote><div><br></div></span></div></div></div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div>The reason there's no discussion about that is that nobody here has the ability to go hunt down every last piece of code in every public or private (think Standard Chartered, Facebook, etc.) code base and its current owner, and order them to "fix" it. You can't win that battle.</div></div><span class="m_7003292863192075632HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="m_7003292863192075632m_-8380864488226383858gmail_signature" data-smartmail="gmail_signature"><div><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</font></span></div></div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div></div></blockquote></div></div>