Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk 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 d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 draft report
I'd appreciate a few more eyes over this, in particular look out for messed up typesetting as there could still be a few bugs lurking. Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the language Haskell 98. Well at least you are complying. :-) In the Preface, my affiliation should be University of York, the one in England, not York University, the one in Canada. Also in the Preface, I would expect a citation for the published version of the Haskell'98 book, together with its appearance in the Bibliography. I did not immediately spot any other obvious flaws. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 draft report
I'd appreciate a few more eyes over this, in particular look out for messed up typesetting as there could still be a few bugs lurking. In the HTML version, there are a few cases where section numbers are missing from the subsection headers in the TOC. I see at least 11 and 22. In the PDF, is there any possibility of formatting the entries in the TOC as links to the text? Regards, Sean ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
