<div dir="ltr">Keep in mind such a package would have to either supply its own definition for Monad, cutting it off from the rest of the world almost entirely and making it near impossible to use with almost any of the existing libraries, or users would have to give up defining any new monads.<div><br></div><div>In the first situation:<br><div><br></div><div>Its notion of Monad would need to be picked by do sugar. Today, this would mean using RebindableSyntax in all the client code. Even then the semantics are subtly wrong. With RebindableSyntax you get whatever one is in local lexical scope, not your pre-selected (>>=) and return, so you'd still be able to see through the facade pretty easily.<br></div><div><div><br></div><div>So, yes, someone could write and maintain a package that doesn't work with anything else and put that package on hackage for backwards compatibility. In fact, we have two packages (haskell98 and haskell2010) that are no longer considered core libraries, which an interested party could step up to turn into something along these lines.</div><div><br></div><div>Herbert spent some time working on implementing a proper version of such a vision and filed a couple of issues on GHC for features he'd need to make it viable, but it hasn't happened yet and is a rather monolithic task.</div><div><br></div><div>Also due to changes in Num, such a package isn't _really_ haskell98 or haskell2010 anyways, so to do the pedantic version you'd need to supply your own Num and instances.</div><div><br></div><div>In the second:</div><div><br></div><div>Alternately, a thinner shim could be written, which just uses the existing classes with their semantic changes and tries not to export anything different than before. This design winds up stitched out of compromises, but could be written and maintained by an interested party out on hackage with no tooling required.</div><div><br></div><div>While nothing is stopping someone from going off and pursuing these options, from a POSIWID perspective the net result is introducing fragmentation in the name of avoiding a few names, and even if someone invests all of the effort to make it happen, it seems to me about half of the parties interested in such a design would want the other of the two options laid out here, exacerbating the fragmentation issue</div><div><br></div><div>-Edward</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 13, 2015 at 7:50 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The Prelude of GHC-7.10/base-4.8 introduces several name clashes mostly due to the AMP and FTP: (<*) clashes with Accelerate, (<*>) clashes with NumericPrelude, (and (<>) would clash with HMatrix if added to Prelude), 'join', 'pure', 'traverse', 'fold' clash with custom defined functions. "import Prelude hiding (pure)" is not yet supported by GHC-7.4 (as shipped with Ubuntu 12.04) and in newer GHC versions it generates an annoying warning. The only remaining option is to explicitly import identifiers from Prelude.<br>
<br>
What about maintaining the pre-AMP+FTP-Prelude in a package on Hackage? Then we could maintain compatibility with a range of GHC versions by disabling import of Prelude and importing preamplified (so to speak) Prelude. The base-compat package seems to support the other way round, that is, providing new 'base' functions to old compilers.<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div><br></div>