What's the future of the haskellYYYY packages?

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

What's the future of the haskellYYYY packages?

Bas van Dijk-2
On 11 November 2011 15:09, Henning Thielemann
<[hidden email]> wrote:
>
> On Fri, 11 Nov 2011, Bas van Dijk wrote:
>
>> I forgot the reason why we need Control.Monad.Instances which exports
>> orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either
>> e):
>
> Compatibility with Haskell 98's Prelude?

Thanks I understand.

What exactly is the future plan of the haskell98 and haskell2010
packages? I understand that the Haskell' Process[1] now only deals
with the Haskell language and that the evolution of the core libraries
is now the responsibility of the Library Submission Process[2]. Does
this mean we stop making haskellYYYY packages?

I think that would be a good thing. Since these packages block
innovation in certain parts of base (for example: getting rid of some
orphaned instances in Control.Monad.Instances or designing a new monad
hierarchy).

Regards,

Bas

[1] http://hackage.haskell.org/trac/haskell-prime/wiki/Process
[2] http://www.haskell.org/haskellwiki/Library_submissions

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

Re: What's the future of the haskellYYYY packages?

Simon Marlow-7
On 11/11/2011 15:06, Bas van Dijk wrote:

> On 11 November 2011 15:09, Henning Thielemann
> <[hidden email]>  wrote:
>>
>> On Fri, 11 Nov 2011, Bas van Dijk wrote:
>>
>>> I forgot the reason why we need Control.Monad.Instances which exports
>>> orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either
>>> e):
>>
>> Compatibility with Haskell 98's Prelude?
>
> Thanks I understand.
>
> What exactly is the future plan of the haskell98 and haskell2010
> packages? I understand that the Haskell' Process[1] now only deals
> with the Haskell language and that the evolution of the core libraries
> is now the responsibility of the Library Submission Process[2]. Does
> this mean we stop making haskellYYYY packages?

I don't think that's true.  Both Haskell 98 and Haskell 2010 specified a
number of library modules, which are implemented by the packages
haskell98 and haskell2010 respectively.  If we want to support those
standards, we have to support their libraries too.

> I think that would be a good thing. Since these packages block
> innovation in certain parts of base (for example: getting rid of some
> orphaned instances in Control.Monad.Instances or designing a new monad
> hierarchy).

They don't necessarily block progress in the base package, they just
mean that more code has to be copied into haskell98/haskell2010 to
maintain the original API.

I'm not sure to what extent we want to do this.  So far we've only had
to copy a few individual functions and fix export lists.  The change to
Num recently meant that we have diverged from Haskell 98 and Haskell
2010 in a fairly fundamental way, and to recover compatibility we would
have to copy a lot of code into haskell98 and haskell2010.  On the other
hand the change doesn't break very much code, so we could let it slip (I
think that's what we'll do).

It would be a shame to drop compatibility for Haskell 2010 only two
years after it was released.  I don't have a good feeling for how
important this is though - certainly not much code on Hackage is written
in pure Haskell 98 or Haskell 2010, but what about course materials and
textbooks?

Cheers,
        Simon

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

Re: What's the future of the haskellYYYY packages?

Colin Paul Adams

    Simon> On 11/11/2011 15:06, Bas van Dijk wrote:

>  I'm not sure to what extent we want to do this.  So far we've only had
>  to copy a few individual functions and fix export lists.  The change
>  to Num recently meant that we have diverged from Haskell 98 and
>  Haskell 2010 in a fairly fundamental way, and to recover compatibility
>  we would have to copy a lot of code into haskell98 and haskell2010.

What's wrong with copying a lot of code? It's not code that's going to
need maintenance is it?
--
Colin Adams
Preston Lancashire
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: What's the future of the haskellYYYY packages?

Simon Marlow-7
On 11/11/2011 16:40, Colin Paul Adams wrote:

>
>      Simon>  On 11/11/2011 15:06, Bas van Dijk wrote:
>
>>   I'm not sure to what extent we want to do this.  So far we've only had
>>   to copy a few individual functions and fix export lists.  The change
>>   to Num recently meant that we have diverged from Haskell 98 and
>>   Haskell 2010 in a fairly fundamental way, and to recover compatibility
>>   we would have to copy a lot of code into haskell98 and haskell2010.
>
> What's wrong with copying a lot of code? It's not code that's going to
> need maintenance is it?

I don't have a big problem with it, no.  It's just the time required to
actually do it - depending on how deep the divergence is, you might have
to pull a lot of the GHC.* modules in the base package over, and the
intermodule dependencies can be quite tricky.  There are the lesser
issues of the extra compile time and disk space for the duplicated
library code too.

Also, the more copying you do, the less it becomes possible to have a
program that consists of a combination of haskell2010 modules and
modules that import the base package.  Essentially it becomes impossible
to have libraries written in pure Haskell 2010.  Again, I don't know how
much we care about that.

Cheers,
        Simon

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

Re: What's the future of the haskellYYYY packages?

Bas van Dijk-2
On 11 November 2011 17:50, Simon Marlow <[hidden email]> wrote:
> Also, the more copying you do, the less it becomes possible to have a
> program that consists of a combination of haskell2010 modules and modules
> that import the base package.  Essentially it becomes impossible to have
> libraries written in pure Haskell 2010.  Again, I don't know how much we
> care about that.

What is the purpose of haskellYYYY if it becomes impossible to combine
(either directly or indirectly) base and haskellYYYY?

Is it just so that book authors can base their books on a stable API?
If so, why can't they just base their books on some version of base
exploiting the PVP?

Cheers,

Bas

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

Re: What's the future of the haskellYYYY packages?

Ben Millwood
On Fri, Nov 11, 2011 at 5:00 PM, Bas van Dijk <[hidden email]> wrote:

> On 11 November 2011 17:50, Simon Marlow <[hidden email]> wrote:
>> Also, the more copying you do, the less it becomes possible to have a
>> program that consists of a combination of haskell2010 modules and modules
>> that import the base package.  Essentially it becomes impossible to have
>> libraries written in pure Haskell 2010.  Again, I don't know how much we
>> care about that.
>
> What is the purpose of haskellYYYY if it becomes impossible to combine
> (either directly or indirectly) base and haskellYYYY?
>
> Is it just so that book authors can base their books on a stable API?
> If so, why can't they just base their books on some version of base
> exploiting the PVP?
>
> Cheers,
>
> Bas
>

My understanding was that base is large and fairly intricate (contains
use of ExistentialQuantification, RankNTypes, and so forth) whereas
haskell2010 is comparatively simple to implement, so there's more hope
that it could be provided by a non-GHC compiler. In practice I suspect
that it's not often used in this way, but I like the idea.

Ben

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries