On Fri, Apr 30, 2010 at 9:18 AM, Bas van Dijk wrote:

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

Surely the latter; that's consistent with the 'haskell98' package, after all. -- gwern

As the issue seems to be that neither base or haskell2010 subsume the other, is it feasible to factor the overlapping fragment into something like a base2010 package that base depends upon. That way importing base you get all of the existing functionality, and then the haskell2010 package can depend on base2010, so importing haskell2010, you also get exactly the subset of functionality expected. If you use both base and haskell2010, then the overlapping fragment is included from the common sub-package. No new extensions are required. The problem here is that it is a slippery slope (do we repeat this process in 2011?) and base-internal/base2010 or whatever it should be called could possibly behind the scenes rely on implementation details from other modules in base, so the aforementioned refactoring could be difficult. -Edward Kmett On Fri, Apr 30, 2010 at 9:48 AM, David Menendez wrote:

On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace 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 <http://www.eyrie.org/~zednenem/ http://www.eyrie.org/%7Ezednenem/> _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

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

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

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

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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH