On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland <mainl...@apeiron.net> wrote:
> On 10/22/2015 01:29 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > > <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> wrote: > > > > > > I am not against changing the Prelude! But it sure would be nice if > > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a > > Haskell 2010 Prelude, both of which could be used with external > > packages > > that themselves used the more modern Prelude. > > > > > > It would definitely be a preferable state of affairs. Unfortunately, > > at least with the tools available to us today, such a plan is > > incompatible with any plan that introduces a new superclass. It also > > cuts off plans that ever factors an existing class into two, such as > > the MonadFail proposals. We simply do not at this time have the > > technical capabilities that would support such a system. If they > > showed up in GHC we can adapt plans to fit. > > Great! > > Could we work to characterize what technical capabilities we would need > to support full backwards Prelude compatibility? > > Here is my rough understanding of what we would need: > > 1) Some method for "default superclasses." This would solve the AMP issue. > > 2) A method for factoring existing classes into two (or more) parts. > This would solve the MonadFail problem. > > 3) A method for imposing extra superclass constraints on a class. This > would be needed for full Num compatibility. Seems much less important > that 1 and 2. > > The most thought has gone into 1. > > Are these three technical capabilities *all* that we would need? Perhaps > we also need a way to tie the current language (-XHaskell98, > -XHaskell2010) to a particular implementation of the Prelude. > I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it. If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications. I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. -Edward
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
