maintaining pre-AMP+FTP-Prelude in external package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

maintaining pre-AMP+FTP-Prelude in external package

Henning Thielemann

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Joachim Breitner-2
Hi,

Am Mittwoch, den 13.05.2015, 13:50 +0200 schrieb Henning Thielemann:
> 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.

if you make that package reexport all modules from base, you would not
even have to change your old code, but only change the dependency from
"base" to your "base-preAMPlified". With module-rexports¹ this is even
possible by simply listing all modules in the cabal file.

It also seems to be similar to the idea of frozen-base packages, as in
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118364.html

Greetings,
Joachim

¹ see https://ghc.haskell.org/trac/ghc/wiki/ModuleReexports
  and https://ghc.haskell.org/trac/ghc/ticket/8407

--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Edward Kmett-2
In reply to this post by Henning Thielemann
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Henning Thielemann

On Wed, 13 May 2015, Edward Kmett wrote:

> 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.

I am only concerned with exported identifiers. Monad class would remain a
sub-class of Applicative, but Applicative is not exported by
PreludePreAMP.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Herbert Valerio Riedel
On 2015-05-13 at 16:38:14 +0200, Henning Thielemann wrote:
> On Wed, 13 May 2015, Edward Kmett wrote:
>
>> 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.
>
> I am only concerned with exported identifiers. Monad class would
> remain a sub-class of Applicative, but Applicative is not exported by
> PreludePreAMP.

But then you won't be able to define Monad instances... :-/

See also the discussion in https://ghc.haskell.org/trac/ghc/ticket/9590
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Felipe Lessa
On 13-05-2015 19:12, Herbert Valerio Riedel wrote:
> On 2015-05-13 at 16:38:14 +0200, Henning Thielemann wrote:
>> I am only concerned with exported identifiers. Monad class would
>> remain a sub-class of Applicative, but Applicative is not exported by
>> PreludePreAMP.
>
> But then you won't be able to define Monad instances... :-/

Just import Applicative from its own module, like we did before GHC 7.10.

AFAIU, the point of having PreludePreAMP would be facilitating
maintenance of code that works both on 7.10 and <= 7.8 without warnings.
 One would still need to know that for defining a Monad they need
Applicative.  That was the best practice for a long time, anyway.

Cheers,

--
Felipe.


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: maintaining pre-AMP+FTP-Prelude in external package

Henning Thielemann
In reply to this post by Herbert Valerio Riedel

On Thu, 14 May 2015, Herbert Valerio Riedel wrote:

> On 2015-05-13 at 16:38:14 +0200, Henning Thielemann wrote:
>>
>> I am only concerned with exported identifiers. Monad class would
>> remain a sub-class of Applicative, but Applicative is not exported by
>> PreludePreAMP.
>
> But then you won't be able to define Monad instances... :-/

I would import Applicative from Control.Applicative like I did until
GHC-7.8.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries