maintaining pre-AMP+FTP-Prelude in external package

[Edward Kmett]

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.

In the first situation:

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.

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.

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.

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.

In the second:

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.

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

-Edward

On Wed, May 13, 2015 at 7:50 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> 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.
>
> 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.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150513/32c0d337/attachment.html>