Haskell 2010 libraries

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

Haskell 2010 libraries

Simon Marlow-7
Hi Folks,

I'm editing the Haskell 2010 report right now, and trying to decide what
to do about the libraries.  During the Haskell 2010 process the
committee agreed that the libraries in the report should be updated,
using the current hierarchical names, adding new functionality from the
current base package, and dropping some of the H'98 library modules that
now have better alternatives.

In Haskell 2010 we're also adding the FFI modules.  The FFI addendum
used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are
usually known by their hierarchical names nowadays: e.g. Foreign.C,
Foreign.Marshal.Alloc.  It would seem strange to add the
non-hierarchical names to the Haskell language report.

So this is all fine from the point of view of the Haskell report - I can
certainly update the report to use the hierarchical module names, but
that presents us with one or two problems in the implementation.

The obvious thing to do would be to make a haskell2010 package that
re-exports the appropriate modules from base, providing a fixed API that
people can depend on when they write Haskell 2010 code.  However, what
happens when someone wants to write some code that uses Haskell 2010
libraries, but also uses something else from base, say
Control.Concurrent?  The modules from haskell2010 overlap with those
from base, so all the imports of Haskell 2010 modules will be ambiguous.
  The Prelude is a bit of a thorny issue too: currently it is in base,
but we would have to move it to haskell2010.

Bear in mind these goals: we want to

   a. support writing code that is Haskell 2010 only: it only uses
      Haskell 2010 language features and modules.

   b. not break existing code as far as possible

   c. whatever we do should extend smoothly when H'2011 makes
      further changes, and so on.

Here are some non-options:

   1. Not have a haskell2010 package.  We lose (a) above, and we
      lose the ability to add or change the API for these modules,
      in base, since they have to conform to the H'2010 spec.  If
      H'2011 makes any changes to these modules, we're really stuck.

   2. As described above: you can either use haskell2010, or base,
      but not both.  It would be painful to use haskell2010 in
      GHCi, none of the base modules would be available.

Here are some options:

   3. allow packages to shadow each other, so haskell2010 shadows
      base.  This is a tantalising possibility, but I don't have
      any idea what it would look like, e.g. should the client or
      the package provider specify shadowing?

   4. Provide a haskell2010 package and a base2010 package that
      re-exports all of base except the modules that overlap with
      haskell2010.  You can either use haskell2010,
      haskell2010+base2010, or base.  This is a bit like (1), but
      avoids the need for shadowing by using package re-exports,
      on the other hand confusion could well arise due to the
      strange base2010 package, and some people would surely try
      to use haskell2010 + base and run into difficulties.

   5. Not have a haskell2010 package, but have the report say that
      implementations are allowed to add things to the standard
      libraries.

Thoughts?  Better ideas?

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Bulat Ziganshin-2
Hello Simon,

Friday, April 30, 2010, 1:42:33 PM, you wrote:

> During the Haskell 2010 process the
> committee agreed that the libraries in the report should be updated,

i think: if committee assignment turned out to be ambiguous, it should
be returned to committee. we can discuss it here but then committee
should make a clear decision


--
Best regards,
 Bulat                            mailto:[hidden email]

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

Re: Haskell 2010 libraries

Malcolm Wallace
In reply to this post by Simon Marlow-7
>  3. allow packages to shadow each other, so haskell2010 shadows
>     base.  This is a tantalising possibility, but I don't have
>     any idea what it would look like, e.g. should the client or
>     the package provider specify shadowing?

This sounds like a potentially complicated new mechanism, introducing  
lots of new subtleties.  Probably not a good idea for that reason alone.

>  4. Provide a haskell2010 package and a base2010 package that
>     re-exports all of base except the modules that overlap with
>     haskell2010.  You can either use haskell2010,
>     haskell2010+base2010, or base.  This is a bit like (1), but
>     avoids the need for shadowing by using package re-exports,
>     on the other hand confusion could well arise due to the
>     strange base2010 package, and some people would surely try
>     to use haskell2010 + base and run into difficulties.

In many ways this corresponds to my preferred solution, although I  
would rephrase it thus:

   * Deprecate use of the "base" package,  (I do not mean to remove  
"base",
     just to freeze it, and discourage its general use.)
   * Create a new "haskell2010" package (for ghc this will be built on  
top
     of "base", but other compilers might make a different choice).
   * Create a new "portablebase" package which contains (or re-exports)
     all of the remaining useful and portable parts of the current  
"base"
     _and_ "haskell2010".
   * Create a new "ghcextras" package which re-exports (or defines  
afresh)
     all of the useful but non-portable parts of the current "base".

So "haskell2010" would be stable and unchanging.  "portablebase" would  
be a superset of "haskell2010", and continue to evolve with community  
input, and parts of it would eventually migrate into "haskell2011",  
"haskell2012", etc.  Meanwhile "ghcextras" would clearly delineate  
those language/library features that are not portable, and it could  
continue to grow, or indeed shrink, with some parts migrating into  
"portablebase" as the language definition adopts extensions, or as  
other compilers adopt implementation strategies.

To illustrate the forward compatibility story, I envisage that when  
"haskell2011" is created, a new version of "portablebase" would depend  
on (and re-export) it instead of "haskell2010".  This would be OK  
because the "portablebase" API would be non-decreasing, and new  
Reports should not make library changes that have not already been  
trialled in the community.  On the other hand, the "ghcextras" package  
would be free to shrink as functionality is gradually transferred to  
"portablebase".

Because I suggest that "portablebase" re-export the "haskell2010" API  
in its entirety, it would be impossible to use both packages  
explicitly at the same time from a single module - users would need to  
choose one or the other.  Also, packages which currently depend on  
"base" should be encouraged to upgrade to a dependency on  
"haskell2010" rather than on "portablebase", if possible, because it  
provides greater stability of interface.

The overall dependency graph would look something like this:

                           /--- stablestuff   /-- less-stable-stuff
                          /                  /
      base ---  haskell2010 --- portablebase ---\
           \--  ghcextras   ---------------------\=== experimental-stuff

> 5. Not have a haskell2010 package, but have the report say that
>     implementations are allowed to add things to the standard
>     libraries.

This seems superficially attractive, but I think it would be  
impossible in practice to guarantee anything.  For instance, the  
semantics of "take" and "drop" changed between Haskell 1.4 and  
Haskell'98 iirc, with no corresponding change in the API.  With  
separate packages it is possible to retain and choose between both  
sets of semantics.

Regards,
     Malcolm

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

Re: Haskell 2010 libraries

Malcolm Wallace
In reply to this post by Bulat Ziganshin-2
>> During the Haskell 2010 process the
>> committee agreed that the libraries in the report should be updated,
>
> i think: if committee assignment turned out to be ambiguous, it should
> be returned to committee. we can discuss it here but then committee
> should make a clear decision

The committee's decision is clear enough.  The question is to do with  
implementation issues that are not specified by the Report.

Regards,
     Malcolm

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

Re: Haskell 2010 libraries

Bas van Dijk-2
In reply to this post by Malcolm Wallace
When you talk about the package "haskell2010" do you mean a package
named "haskell" with major version "2010" as in "haskell-2010" or a
package actually named "haskell2010"?

Regards,

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

Re: Haskell 2010 libraries

David Menendez-2
In reply to this post by Malcolm Wallace
On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace
<[hidden email]> wrote:
> Because I suggest that "portablebase" re-export the "haskell2010" API in its
> entirety, it would be impossible to use both packages explicitly at the same
> time from a single module - users would need to choose one or the other.

Is the idea that portablebase re-exports modules at the same name? If
so, does Haskell2010 allow for package-qualified imports or would
portablebase require extensions?

--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Christian Maeder-2
In reply to this post by Malcolm Wallace
Malcolm Wallace schrieb:

> In many ways this corresponds to my preferred solution, although I would
> rephrase it thus:
>
>   * Deprecate use of the "base" package,  (I do not mean to remove "base",
>     just to freeze it, and discourage its general use.)
>   * Create a new "haskell2010" package (for ghc this will be built on top
>     of "base", but other compilers might make a different choice).
>   * Create a new "portablebase" package which contains (or re-exports)
>     all of the remaining useful and portable parts of the current "base"
>     _and_ "haskell2010".
>   * Create a new "ghcextras" package which re-exports (or defines afresh)
>     all of the useful but non-portable parts of the current "base".
>
> So "haskell2010" would be stable and unchanging.  "portablebase" would
> be a superset of "haskell2010", and continue to evolve with community
> input, and parts of it would eventually migrate into "haskell2011",
> "haskell2012", etc.  Meanwhile "ghcextras" would clearly delineate those
> language/library features that are not portable, and it could continue
> to grow, or indeed shrink, with some parts migrating into "portablebase"
> as the language definition adopts extensions, or as other compilers
> adopt implementation strategies.
>
> To illustrate the forward compatibility story, I envisage that when
> "haskell2011" is created, a new version of "portablebase" would depend
> on (and re-export) it instead of "haskell2010".  This would be OK
> because the "portablebase" API would be non-decreasing, and new Reports
> should not make library changes that have not already been trialled in
> the community.  On the other hand, the "ghcextras" package would be free
> to shrink as functionality is gradually transferred to "portablebase".
>
> Because I suggest that "portablebase" re-export the "haskell2010" API in
> its entirety, it would be impossible to use both packages explicitly at
> the same time from a single module - users would need to choose one or
> the other.  Also, packages which currently depend on "base" should be
> encouraged to upgrade to a dependency on "haskell2010" rather than on
> "portablebase", if possible, because it provides greater stability of
> interface.
>
> The overall dependency graph would look something like this:
>
>                           /--- stablestuff   /-- less-stable-stuff
>                          /                  /
>      base ---  haskell2010 --- portablebase ---\
>           \--  ghcextras   ---------------------\=== experimental-stuff

Why do you want portablebase to be a superset of haskell2010 by
re-export? Is it not better to have a package "baseextras" that depends
on haskell2010 but only exports additional modules.

Other packages can decide to depend on "haskell2010" only or on
"haskell2010" and "baseextras" (instead of "portablebase" alone).

Or do you want modules from "haskell2010" also to be "portablebase" but
with additional functions (rather than putting new functions into new
modules)?

Cheers Christian

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

Re: Haskell 2010 libraries

Simon Marlow-7
In reply to this post by Malcolm Wallace
On 30/04/10 13:19, Malcolm Wallace wrote:

>> 4. Provide a haskell2010 package and a base2010 package that
>> re-exports all of base except the modules that overlap with
>> haskell2010. You can either use haskell2010,
>> haskell2010+base2010, or base. This is a bit like (1), but
>> avoids the need for shadowing by using package re-exports,
>> on the other hand confusion could well arise due to the
>> strange base2010 package, and some people would surely try
>> to use haskell2010 + base and run into difficulties.
>
> In many ways this corresponds to my preferred solution, although I would
> rephrase it thus:
>
> * Deprecate use of the "base" package, (I do not mean to remove "base",
> just to freeze it, and discourage its general use.)
> * Create a new "haskell2010" package (for ghc this will be built on topcommon
> of "base", but other compilers might make a different choice).
> * Create a new "portablebase" package which contains (or re-exports)
> all of the remaining useful and portable parts of the current "base"
> _and_ "haskell2010".
> * Create a new "ghcextras" package which re-exports (or defines afresh)
> all of the useful but non-portable parts of the current "base".

So it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
that's the crucial difference.

I described this as a non-option because I thought trying to use the
packages together might be a common problem that leads to obscure error
messages about ambiguous modules, but perhaps it's not that bad, or at
least not worse than the other solutions.

I think we can leave the question of whether to abstract the existing
base into separate "portablebase" and "ghcextras" packages as a separate
issue - there are merits to doing something like this for sure, but I'd
like to focus specifically on Haskell 2010, and I think
portablebase/ghcextras are orthogonal.

> Because I suggest that "portablebase" re-export the "haskell2010" API in
> its entirety, it would be impossible to use both packages explicitly at
> the same time from a single module - users would need to choose one or
> the other. Also, packages which currently depend on "base" should be
> encouraged to upgrade to a dependency on "haskell2010" rather than on
> "portablebase", if possible, because it provides greater stability of
> interface.

We hope in the future that the set of libraries standardised in the
report grows beyond what we have in base currently, so I'm not sure how
much sense it makes for portablebase to re-export the haskell20xx
modules.  Generally speaking we've been tyring to make base smaller
rather than larger.  Indeed right now there are some modules in the
report that aren't in base, although those are the ones we're
considering removing in this iteration.

I like the picture where we have a small base, lots of independent
packages, and one or more haskell20xx packages that re-exports all the
standardised stuff from the other packages.  This arrangement extends
smoothly, the only problem is that haskell20xx overlaps with the other
packages.

>> 5. Not have a haskell2010 package, but have the report say that
>> implementations are allowed to add things to the standard
>> libraries.
>
> This seems superficially attractive, but I think it would be impossible
> in practice to guarantee anything. For instance, the semantics of "take"
> and "drop" changed between Haskell 1.4 and Haskell'98 iirc, with no
> corresponding change in the API. With separate packages it is possible
> to retain and choose between both sets of semantics.

Yes, I agree - that's a non starter.

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Ian Lynagh
On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:

> On 30/04/10 13:19, Malcolm Wallace wrote:
>>> 4. Provide a haskell2010 package and a base2010 package that
>>> re-exports all of base except the modules that overlap with
>>> haskell2010. You can either use haskell2010,
>>> haskell2010+base2010, or base. This is a bit like (1), but
>>> avoids the need for shadowing by using package re-exports,
>>> on the other hand confusion could well arise due to the
>>> strange base2010 package, and some people would surely try
>>> to use haskell2010 + base and run into difficulties.
>>
>> In many ways this corresponds to my preferred solution, although I would
>> rephrase it thus:
>>
>> * Deprecate use of the "base" package, (I do not mean to remove "base",
>> just to freeze it, and discourage its general use.)
>> * Create a new "haskell2010" package (for ghc this will be built on topcommon
>> of "base", but other compilers might make a different choice).
>> * Create a new "portablebase" package which contains (or re-exports)
>> all of the remaining useful and portable parts of the current "base"
>> _and_ "haskell2010".
>> * Create a new "ghcextras" package which re-exports (or defines afresh)
>> all of the useful but non-portable parts of the current "base".
>
> So it seems this is closer to option (2) in my message, because  
> portablebase and haskell2010 overlap, and are therefore mutually  
> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -  
> that's the crucial difference.

If they are non-overlapping, how would a new Data.List function be
added? Or an existing Data.List function be altered?

No matter what solution is chosen, changes to datatypes or classes seem
likely to be troublesome.

I think the library change plans are underdeveloped, the libraries
should be unchanged in H2010, and we should resolve this issue before
changing them in a future language revision. That would keep other
options open, such as the report standardising Haskell2011.Data.List
rather than Data.List, etc.

> I described this as a non-option because I thought trying to use the  
> packages together might be a common problem that leads to obscure error  
> messages about ambiguous modules, but perhaps it's not that bad, or at  
> least not worse than the other solutions.

Direct imports of base* and haskell* could be (dis)allowed by the
implementation depending on whether it is in "Haskell 2010 mode" or not.

> We hope in the future that the set of libraries standardised in the  
> report grows beyond what we have in base currently

Oh, I thought the plan was for library standardisation in the report to
be reduced, with perhaps the Haskell Platform becoming the new library
standardisation effort.


Thanks
Ian

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

Re: Haskell 2010 libraries

Simon Marlow-7
On 01/05/10 17:16, Ian Lynagh wrote:

>> So it seems this is closer to option (2) in my message, because
>> portablebase and haskell2010 overlap, and are therefore mutually
>> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
>> that's the crucial difference.
>
> If they are non-overlapping, how would a new Data.List function be
> added? Or an existing Data.List function be altered?

In this scenario there would be base as it is now, and base2010 (or
whatever you want to call it) that is base minus the modules in
haskell2010.  So you can add things to base:Data.List, but
haskell2010:Data.List must export exactly the API as specified in the
report.

> No matter what solution is chosen, changes to datatypes or classes seem
> likely to be troublesome.

Yes, that's true. Adding methods to classes is possible, but adding
constructors to datatypes, or new instances, is not.

> I think the library change plans are underdeveloped, the libraries
> should be unchanged in H2010, and we should resolve this issue before
> changing them in a future language revision. That would keep other
> options open, such as the report standardising Haskell2011.Data.List
> rather than Data.List, etc.

FWIW, I omitted mentioning that option because I think it's the worst of
the bunch :-)  I think that putting version numbers into module names is
a very dangerous thing to start doing.  When you want to upgrade your
code to Haskell 2011, you have to change not just the .cabal file but
all the imports too.  Keeping version dependencies collected together in
one place and not scattered through source code is one of the better
design decisions we made, I believe.

Doing "nothing" as you suggest is an option, but it would mean using the
non-hierarchical names for the FFI libraries.  There's nothing
technically wrong with it, but I find it a bit odd to be standardising
modules with names that in practice almost no code has ever used.  I
suppose those are the names in the FFI addendum though.

>> I described this as a non-option because I thought trying to use the
>> packages together might be a common problem that leads to obscure error
>> messages about ambiguous modules, but perhaps it's not that bad, or at
>> least not worse than the other solutions.
>
> Direct imports of base* and haskell* could be (dis)allowed by the
> implementation depending on whether it is in "Haskell 2010 mode" or not.

Not sure what you mean here - modules are imported, not packages.  Type
error!

It's the modules that overlap between the two packages that are the
problem.  If someone imports Data.List, do they mean the haskell2010 or
the base one?  If you're suggesting that we choose based on whether the
flag -fhaskell2010 is set, then that really amounts to the haskell2010
package shadowing base when -fhaskell2010 is on.  It might be the right
thing, but it's a slightly ugly special case.

>> We hope in the future that the set of libraries standardised in the
>> report grows beyond what we have in base currently
>
> Oh, I thought the plan was for library standardisation in the report to
> be reduced, with perhaps the Haskell Platform becoming the new library
> standardisation effort.

I thought the *eventual* plan was to properly standardise lots of
libraries, with the Haskell Platform being an intermediate step on the
way to standardisation. Though I don't think we ever actually decided
anything, really.

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Simon Marlow-7
In reply to this post by Simon Marlow-7
On 30/04/10 23:52, Felipe Lessa wrote:

> On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
>> I like the picture where we have a small base, lots of independent
>> packages, and one or more haskell20xx packages that re-exports all
>> the standardised stuff from the other packages.  This arrangement
>> extends smoothly, the only problem is that haskell20xx overlaps with
>> the other packages.
>
> I wonder how much pain will there be when Haskell 2011 comes out.
> Some packages will depend on haskell2010, and others on
> haskell2011.  Will they integrate and compile fine?
>
> If haskell2010 is a metapackage that says
>
>    Depends: base == X.Y.*
>
> and haskell2011 is another metapackage that says
>
>    Depends: base == Z.W.*
>
> then I think we're going to have big problems.  Sorry if this is
> a resolved issue. :)

That won't be a problem, for the same reasons that we can happily mix
packages that depend on base-3 with packages that depend on base-4 right
now.

That is, unless Haskell 2011 decides to make some incompatible changes
to datatypes or classes, as Ian pointed out.

Cheers,
        Simon

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

Re: Haskell 2010 libraries

Ian Lynagh
In reply to this post by Simon Marlow-7
On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:

> On 01/05/10 17:16, Ian Lynagh wrote:
>
>>> So it seems this is closer to option (2) in my message, because
>>> portablebase and haskell2010 overlap, and are therefore mutually
>>> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
>>> that's the crucial difference.
>>
>> If they are non-overlapping, how would a new Data.List function be
>> added? Or an existing Data.List function be altered?
>
> In this scenario there would be base as it is now, and base2010 (or  
> whatever you want to call it) that is base minus the modules in  
> haskell2010.  So you can add things to base:Data.List, but  
> haskell2010:Data.List must export exactly the API as specified in the  
> report.

So someone using haskell2010+base2010 wouldn't be able to use this new
function?

>>> I described this as a non-option because I thought trying to use the
>>> packages together might be a common problem that leads to obscure error
>>> messages about ambiguous modules, but perhaps it's not that bad, or at
>>> least not worse than the other solutions.
>>
>> Direct imports of base* and haskell* could be (dis)allowed by the
>> implementation depending on whether it is in "Haskell 2010 mode" or not.
>
> Not sure what you mean here - modules are imported, not packages.  Type  
> error!

Heh, true. I meant that e.g.
    ghc --language haskell2010 -package base ...
would give an error.


Thanks
Ian

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

Re: Haskell 2010 libraries

Brandon S Allbery KF8NH
In reply to this post by Simon Marlow-7
On May 1, 2010, at 15:05 , Simon Marlow wrote:

> On 01/05/10 17:16, Ian Lynagh wrote:
>> Oh, I thought the plan was for library standardisation in the  
>> report to
>> be reduced, with perhaps the Haskell Platform becoming the new  
>> library
>> standardisation effort.
>
> I thought the *eventual* plan was to properly standardise lots of  
> libraries, with the Haskell Platform being an intermediate step on  
> the way to standardisation. Though I don't think we ever actually  
> decided anything, really.

I was also under the impression that the Haskell Platform was the  
library standardization effort (and in fact my first reaction to your  
original message was "so defer it to the Libraries Report which  
describes the HP", but I wasn't sure I understood all the issues).

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

PGP.sig (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Simon Marlow-7
In reply to this post by Ian Lynagh
On 01/05/10 20:17, Ian Lynagh wrote:

> On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:
>> On 01/05/10 17:16, Ian Lynagh wrote:
>>
>>>> So it seems this is closer to option (2) in my message, because
>>>> portablebase and haskell2010 overlap, and are therefore mutually
>>>> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
>>>> that's the crucial difference.
>>>
>>> If they are non-overlapping, how would a new Data.List function be
>>> added? Or an existing Data.List function be altered?
>>
>> In this scenario there would be base as it is now, and base2010 (or
>> whatever you want to call it) that is base minus the modules in
>> haskell2010.  So you can add things to base:Data.List, but
>> haskell2010:Data.List must export exactly the API as specified in the
>> report.
>
> So someone using haskell2010+base2010 wouldn't be able to use this new
> function?

Correct.  If you opt to use the Haskell 2010 API, you don't get to see
new additions made to those modules, but that's entirely reasonable.

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Haskell 2010 libraries

Duncan Coutts-4
In reply to this post by Simon Marlow-7
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:

> Here are some options:
>
>    3. allow packages to shadow each other, so haskell2010 shadows
>       base.  This is a tantalising possibility, but I don't have
>       any idea what it would look like, e.g. should the client or
>       the package provider specify shadowing?

Note that we already have some notion of shadowing. Modules found in
local .hs files shadow modules from packages.

Duncan

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

Re: Haskell 2010 libraries

Duncan Coutts-4
In reply to this post by Simon Marlow-7
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:

> Hi Folks,
>
> I'm editing the Haskell 2010 report right now, and trying to decide what
> to do about the libraries.  During the Haskell 2010 process the
> committee agreed that the libraries in the report should be updated,
> using the current hierarchical names, adding new functionality from the
> current base package, and dropping some of the H'98 library modules that
> now have better alternatives.
>
> In Haskell 2010 we're also adding the FFI modules.  The FFI addendum
> used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are
> usually known by their hierarchical names nowadays: e.g. Foreign.C,
> Foreign.Marshal.Alloc.  It would seem strange to add the
> non-hierarchical names to the Haskell language report.
>
> So this is all fine from the point of view of the Haskell report - I can
> certainly update the report to use the hierarchical module names, but
> that presents us with one or two problems in the implementation.
>
> However, what happens when someone wants to write some code that uses
> Haskell 2010 libraries, but also uses something else from base, say
> Control.Concurrent?  The modules from haskell2010 overlap with those
> from base, so all the imports of Haskell 2010 modules will be ambiguous.

>   The Prelude is a bit of a thorny issue too: currently it is in base,
> but we would have to move it to haskell2010.

This problem with the Prelude also already exists. It is currently not
possible to write a H98-only program that depends only on the haskell98
package and not on the base package, because the Prelude is exported
from base and not from haskell98.

> Bear in mind these goals: we want to
>
>    a. support writing code that is Haskell 2010 only: it only uses
>       Haskell 2010 language features and modules.
>
>    b. not break existing code as far as possible
>
>    c. whatever we do should extend smoothly when H'2011 makes
>       further changes, and so on.
>
> Here are some non-options:
>
>    1. Not have a haskell2010 package.  We lose (a) above, and we
>       lose the ability to add or change the API for these modules,
>       in base, since they have to conform to the H'2010 spec.  If
>       H'2011 makes any changes to these modules, we're really stuck.
>
>    2. As described above: you can either use haskell2010, or base,
>       but not both.  It would be painful to use haskell2010 in
>       GHCi, none of the base modules would be available.
>
> Here are some options:
>
>    3. allow packages to shadow each other, so haskell2010 shadows
>       base.  This is a tantalising possibility, but I don't have
>       any idea what it would look like, e.g. should the client or
>       the package provider specify shadowing?

So one option is simply to have the client specify shadowing by the
order in which packages are listed on the command line / in the .cabal
file (or some other compiler-dependent mechanism).

If people think the order in the .cabal file is not sufficiently
explicit then I'm sure we can concoct some more explicit syntax. We
already need to add some syntax to allow a package to depend on multiple
versions of a single dependency.

The advantage of the client doing it is it's quite general. The downside
is it's quite general: people can do it anywhere and can easily get
incompatible collections of types. For example base:Prelude.Int would
only be the same as haskell2010:Prelude.Int because it is explicitly set
up to be that way. Arbitrary shadowing would not be so co-operative.


The provider doing it seems fairly attractive. Cases of co-operative
overlapping have to be explicitly constructed by the providing packages
anyway (see e.g. base3 and base4).

I'm not quite sure how it would be implemented but from the user's point
of view they just list the package dependencies as usual and get the
sensible overlapping order. Presumably packages not designed to be used
in an overlapping way should still give an error message.

The provider doing it rather than the client should avoid the user
having to think too much or there being too many opportunities to do
foolish and confusing things. Only the sensible combinations should
work.

> Thoughts?  Better ideas?

So I think I quite like option 3. I doesn't sound to me as complicated
or as subtle as Malcolm seems to fear.

If I write:

build-depends: base, haskell2010

then since haskell2010 has been explicitly set up for this overlapping
to be allowed, then we get haskell2010 shadowing base (irrespective of
the order in which the client lists the packages).

Duncan

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

Re: Haskell 2010 libraries

Brandon S Allbery KF8NH
On May 4, 2010, at 05:09 , Duncan Coutts wrote:
> On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
>> Bear in mind these goals: we want to
>>
>>   a. support writing code that is Haskell 2010 only: it only uses
>>      Haskell 2010 language features and modules.
>>
>>   b. not break existing code as far as possible

I'm going to dissent here:  current code assumes extensions, not a  
standard.  I think it's not outside the pale to have code that wishes  
to conform to Haskell2010 be modified to do so, and otherwise the code  
continues to be "extended nonstandard Haskell" if it is not already  
Haskell98-conformant.  After all, Haskell2010 doesn't quite include  
*all* of the extensions that are in common use.

So, I'm going to go out on a limb here and suggest that Haskell 2010  
code should specify

 > {-# LANGUAGE Haskell2010 #-}

to distinguish from Haskell '98 code (no LANGUAGE pragmas) and  
extension code (other LANGUAGE pragmas).  Users who wish to combine  
the above with nonstandard extensions can expect to do extra work.  
Existing code continues to work because it doesn't explicitly limit  
itself to Haskell2010.

A side benefit of this is that it requires the code (not a cabal file  
or etc.) to specify that it is Haskell2010 as opposed to Haskell98 or  
etc.  Unless cabal-install is a mandatory part of Haskell2010, relying  
on it to specify the language support level strikes me as not the best  
of ideas.

> If people think the order in the .cabal file is not sufficiently
> explicit then I'm sure we can concoct some more explicit syntax. We
> already need to add some syntax to allow a package to depend on  
> multiple
> versions of a single dependency.

We already have most of that, don't we?  There's the extension to  
allow you to specify the exact package to use for a given module; with  
"as" syntax one might presumably say something like

 > import "haskell-2010" Data.List
 > import "containers-ext" Data.List as L;

I understand this may require some work, but it seems a reasonable  
extension of existing syntax.  It also puts the onus of making things  
work together on the user, and (as mentioned above) I think that's  
eminently sensible for existing code that assumes that it uses  
extensions, not a standard.

> The advantage of the client doing it is it's quite general. The  
> downside
> is it's quite general: people can do it anywhere and can easily get
> incompatible collections of types. For example base:Prelude.Int would
> only be the same as haskell2010:Prelude.Int because it is explicitly  
> set
> up to be that way. Arbitrary shadowing would not be so co-operative.

ghc already lets you do this by rebinding syntax.  What happens if you  
rebind (>>=) in a way that isn't quite compatible with the monad  
laws?  Granted, right now you have to do fairly esoteric stuff to get  
yourself into that kind of trouble, whereas we're talking now about  
something likely to be more common.

> I'm not quite sure how it would be implemented but from the user's  
> point
> of view they just list the package dependencies as usual and get the
> sensible overlapping order. Presumably packages not designed to be  
> used
> in an overlapping way should still give an error message.

The problem here is, how do you know?  I recall suggesting some time  
back that dependencies without an upper bound were going to be a  
problem, and lo and behold, when base-4 came out they broke.  If a  
package declares itself to be capable of overlapping, does it apply  
only to Haskell2010 or is it assumed to also apply to Haskell2011  
unless specified otherwise?  Or do we try to figure it out  
automatically?  (Which I suspect would cause all sorts of problems.)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime

PGP.sig (202 bytes) Download Attachment