Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH
PGP.sig
Description: This is a digitally signed message part
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010 libraries
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] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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 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
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 01:57:34PM +0100, Ian Lynagh wrote:
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote:
On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
To take one example, since List was immortalised in the H98 report with
104 exports, Data.List has gained an additional 7 exports:
The last change (making the behaviour of the generic* functions
consistent with their non-generic counterparts) was less than a year
ago, and the last additions were less than 2.
Though also note that we have not changed any of the existing ones.
Yes we have, less than a year ago:
Also, we've just had a proposal to change some others:
Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
http://hackage.haskell.org/trac/ghc/ticket/3399
Both functions are spec in List in haskell98:
http://haskell.org/onlinereport/list.html
Thanks
Ian
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote:
On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote:
On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote:
Specifically, I suggest:
4. Ixkeep as Data.Ix
5. Array keep as Data.Array
Though also note that we have not changed any of the existing ones. Is
there a problem with specifying in the libraries section of the report
that the exports are a minimum and not a maximum?
Here's another example I've just been looking at:
Prelude Array.listArray (1,4) [1..4] Array.! 5
*** Exception: Ix{Integer}.index: Index (5) out of range ((1,4))
Prelude Array.listArray ((0,0), (3,3)) (repeat 0) Array.! (0,5)
*** Exception: Error in array index
Because the Ix Integer instance is for a type that we have a Show
instance for, it can give a nice out-of-bounds error message.
But the Ix (a, b) instance doesn't know if (Show a, Show b)
instances exist, so it has to fall back to an unhelpful error message.
So one could certainly argue that we should make Show a superclass of
Ix, leaving us with a class that is incompatible with the older class
definition.
Thanks
Ian
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
Simon Marlow wrote: Ian Lynagh wrote: Simon Marlow wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. That's the case with base-3/base-4 at the moment. Is it a problem? I think the issue raised is the diamond import problem, for instance that say the list type from haskell-std-2010 is spuriously different from the one in haskell-std-2011 . This would affect new programs based on the 2011 standard that want to use older libraries based on the 2010 standard; the point being that the latter are intentionally not updated to the newer standard. Of course, that's just the base-3 / base-4 issue which can be solved; it's just that it's not automatic but needs explicit work by implementors every time there is a new library standard. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Thu, Jul 16, 2009 at 4:36 AM, Simon Marlowmarlo...@gmail.com wrote: On 15/07/2009 18:10, David Menendez wrote: On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlowmarlo...@gmail.com wrote: On 15/07/2009 15:54, Ian Lynagh wrote: On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. That's the case with base-3/base-4 at the moment. Is it a problem? Could I use two packages of arrow code which depend on base 3.0.2 and base 3.0.3, respectively, in the same project? No. (though I'm not sure the significance of arrow code here). Is there a package that depends on base-3.0.2, and doesn't work with base-3.0.3? Any package that defines an Arrow instance can't work with both 3.0.2 and 3.0.3, because they provide incompatible class definitions. (That's where Category was introduced.) It broke at least one package at the time, although I think it's been fixed by now. In http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015774.html, you argued: We simply *can't* provide the same API as base-3.0.2 without defining a new Arrow class, and that would kill compatibility with base-4. On the other hand, we did know this could happen (changes to datatypes also cause the same problem), it's the tradeoff with trying to provide base-3 as a compatibility layer over base-4. Which is probably the right call for obscure classes like Arrow, but not more common ones like Num or Monad. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ -- 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
On 14/07/2009 15:04, Ian Lynagh wrote: On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. That would be OK with me, although I still think it would be easier for us to disentangle the library standardisation effort from the language standardisation effort. I'd suggest Haskell.V2010.Data.List (just re-exports from V2011 where possible) Haskell.V2010.Prelude (just re-exports from V2011 where possible) Haskell.V2011.Data.List Haskell.V2011.Prelude with the implicit Prelude import being changed to Haskell.Vversion.Prelude whereversion is that latest the compiler supports, unless you say e.g. -XHaskell2010. I find this rather jarring, because it moves versioning from where it should be (in the package metadata) to where it shouldn't be (in the module names). So why can't we use package versioning to do this? Suppose we have a 'haskell-std' package, with versions starting at 2010, providing modules like Data.List. The problem is that haskell-std:Data.List overlaps with base:Data.List. But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 (or does it have to be haskell-std-2010.0?) In some ways this is nice, because we will be able to keep old versions of haskell-std much longer than we can keep old versions of base. And in due course, we can move more modules into haskell-std. That makes an incremental approach to library standardisation possible, in the same way as we have modularised the language standardisation process. So, if we have standard Haskell library modules, then I believe they should be separate at the package level (as they are now). Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On 15/07/2009 15:47, Sittampalam, Ganesh wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like But this precludes the kind of changes to those modules that Ian described as having happened in the last few years. I don't follow. If we have versioned haskell-std packages, surely they can export different APIs? Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On 15/07/2009 15:54, Ian Lynagh wrote: On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. That's the case with base-3/base-4 at the moment. Is it a problem? Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
Would it be possible for the language to require that implementations support linking multiple versions of packages (at least base and haskell-std) into a single running instance? That would solve the issue of using two libs that depend on different versions. On Wed, Jul 15, 2009 at 10:54 AM, Ian Lynaghig...@earth.li wrote: On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote: But there's a solution: we could remove the standard modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 10:48:36 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Ian, Tuesday, July 14, 2009, 3:20:42 AM, you wrote: We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. with your idea we will have two things that address the same problem, and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules -- 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
A natural language consists of a vocabulary of words, as well as a grammar for stringing them together. If we omit the common basic libraries from the language definition, then are we implicitly reducing the common vocabulary, and encouraging dialects to appear? If I see the function scanr in a module, should I expect that it has the semantics of Data.List.scanr? Or is it OK for someone to define their own Data.List with different semantics? Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. I would largely concur with this policy, with the caveat that additions to the API might appear in future. Also, the hierarchical versions of the FFI libraries are essential. 3. Numeric keep as Numeric (?) I think we could take the opportunity to rename it to Text.Numeric. Why Text? Because it only defines ReadS and ShowS things (with the exception of fromRat, and floatToDigits, sigh, which should be moved elsewhere). It'd be nice to have a clear dividing line of keeping the pure stuff and dropping the bits for interacting with the system ... The bits for interacting with the system are of course exactly the bits that are most prone to change and are most in need of improvement. In some ways, it is _more_ important to standardise the difficult bits, i.e. interacting with the system, because otherwise it is desparately difficult to write portable programs. But I agree that the choices made in H'98 and earlier to abstract over the underlying OS were probably rather poor and inflexible, and it is probably unrealistic to be able to propose a new stable API for a couple of years yet. I do think we should set it as a goal for the future however. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Re[4]: Haskell 2010: libraries
Bulat Ziganshin wrote: Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. Do you mean the syntax that allows modules to be imported from a specified package? If so I didn't realise this was implemented by anything more than GHC. with your idea we will have two things that address the same problem, Arguably it is the ability to import from a specified package that duplicates the disambiguation mechanism provided by module names. and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules I'd expect the Haskell2010.* etc to be implemented in a haskell2010 package which depends on the relevant version of base. Obviously it would need to be updated when base was changed incompatibly. Having a library standard implies that implementations must support it for some period of time. I don't see why namespacing the libraries of that standard makes that any harder. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Specifically, I suggest: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ix keep as Data.Ix 5. Array keep as Data.Array 6. Listkeep as Data.List 7. Maybe keep as Data.Maybe 8. Charkeep as Data.Char 9. Monad keep as Control.Monad 10. IO keep as System.IO 11. Directory drop 12. System drop (superseded by System.Process) 13. Timedrop 14. Locale drop 15. CPUTime drop 16. Random drop We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. In some cases, such as the changes to how exceptions work, we haven't had this freedom as the relevant functions are exposed by the Prelude, and that has been causing us grief for years. To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: foldl' foldl1' intercalate isInfixOf permutations stripPrefix subsequences The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. Though also note that we have not changed any of the existing ones. Is there a problem with specifying in the libraries section of the report that the exports are a minimum and not a maximum? But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate base libraries standard. Some functions, especially the pure ones are really part of the character of the language (and some are specified as part of the syntax). We have not had major problems with the pure parts of the standard libraries, our problems have almost all been with the system facing parts (handles, files, programs, exceptions). I don't see any particular problem with having some essential (in the sense of being part of the essence of the language) libraries in the main report and some separate libraries report in a year or two's time standardising some of the trickier aspects of libraries for portable programs to interact with the OS (addressing Malcolm's point about the need for this so as to be able to write portable programs). Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. Though also note that we have not changed any of the existing ones. Yes we have, less than a year ago: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude Data.List.genericTake (-1) abc *** Exception: List.genericTake: negative argument GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude Data.List.genericTake (-1) abc Is there a problem with specifying in the libraries section of the report that the exports are a minimum and not a maximum? We wouldn't be able to fix the generic* functions, or the way exceptions work. But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate base libraries standard. Some functions, especially the pure ones are really part of the character of the language The Haskell language could be thought of as being composed of Haskell Language 2010 report and Haskell Libraries 1.0 report. (and some are specified as part of the syntax) Yes, some types functions may need to be specified by the report as being somewhere for desugaring etc. Although maybe we could even eliminate most of these if rebindable syntax became part of the language? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 11:57:11AM +0400, Bulat Ziganshin wrote: Tuesday, July 14, 2009, 3:20:42 AM, you wrote: We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year Standardising the number of modules we're talking about isn't going to affect whether or not this happens. Also, just because the libraries are standardised separately doesn't mean that we /need/ to change them every year, it just makes it /possible/ to change them. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. That would be OK with me, although I still think it would be easier for us to disentangle the library standardisation effort from the language standardisation effort. I'd suggest Haskell.V2010.Data.List (just re-exports from V2011 where possible) Haskell.V2010.Prelude (just re-exports from V2011 where possible) Haskell.V2011.Data.List Haskell.V2011.Prelude with the implicit Prelude import being changed to Haskell.Vversion.Prelude where version is that latest the compiler supports, unless you say e.g. -XHaskell2010. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote: I'm mainly concerned with projecting a consistent picture in the Report, so as not to mislead or confuse people. Here are the options I can see: 2. Just drop the obvious candidates (Time, Random, CPUTime, Locale, Complex?), leaving the others. 3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. Also it would seem slightly strange to have a seemingly random set of library modules in the report. 4. Combine 2 and 3: drop some, rename the rest. I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Specifically, I suggest: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ix keep as Data.Ix 5. Array keep as Data.Array 6. Listkeep as Data.List 7. Maybe keep as Data.Maybe 8. Charkeep as Data.Char 9. Monad keep as Control.Monad 10. IO keep as System.IO 11. Directory drop 12. System drop (superseded by System.Process) 13. Timedrop 14. Locale drop 15. CPUTime drop 16. Random drop The slightly odd thing here is keeping System.IO but dropping the other IO libs Directory and System. We obviously have to drop System, because it's more or less a deprecated API and it's superseded by System.Process (which we almost certainly do not want to standardise at this stage). It'd be nice to have a clear dividing line of keeping the pure stuff and dropping the bits for interacting with the system however we have to keep System.IO since bits of it are re-exported through the Prelude (unless we also trim the Prelude). The bits for interacting with the system are of course exactly the bits that are most prone to change and are most in need of improvement. Another quirk is that we never changed the name of the Numeric module. Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Mon, 2009-07-13 at 21:57 +0100, Duncan Coutts wrote: On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote: I'm mainly concerned with projecting a consistent picture in the Report, so as not to mislead or confuse people. Here are the options I can see: 2. Just drop the obvious candidates (Time, Random, CPUTime, Locale, Complex?), leaving the others. 3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. Also it would seem slightly strange to have a seemingly random set of library modules in the report. Another thing we can do here is specify that the contents of these modules is a minimum and not a maximum, allowing additions through the usual library proposal process. 4. Combine 2 and 3: drop some, rename the rest. I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Oh and additionally include the FFI modules under their new names. Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Specifically, I suggest: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ixkeep as Data.Ix 5. Array keep as Data.Array 6. List keep as Data.List 7. Maybe keep as Data.Maybe 8. Char keep as Data.Char 9. Monad keep as Control.Monad 10. IOkeep as System.IO 11. Directory drop 12. Systemdrop (superseded by System.Process) 13. Time drop 14. Localedrop 15. CPUTime drop 16. Randomdrop We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. In some cases, such as the changes to how exceptions work, we haven't had this freedom as the relevant functions are exposed by the Prelude, and that has been causing us grief for years. To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: foldl' foldl1' intercalate isInfixOf permutations stripPrefix subsequences The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. It seems unlikely to me that all these libraries are finally perfect. If we freeze them too solidly then I'm sure that we will regret it. It is true that, with yearly language revisions, we have an annual opportunity to fix any problems. However, we also want the implementations to support several releases at once, and maintaining those old base libraries would be a lot of work and confusion for the minimal amount of benefit they would provide. But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate base libraries standard. We would be able to act as if they were one standard if that were most convenient, but we would have the flexibility to take advantage of them being separate if necessary. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
Ross Paterson: On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary. Some of the loose ends: The defaulting rules (section 4.3.4) apply to any class defined in the Prelude or a standard library. The non-Prelude classes involved are Ix and Random. The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move to the Prelude when the non-library part of the FFI spec is incorporated into the Report? If we have these types in the Prelude, the associated functions should be in the Prelude, too, and I'd be reluctant to include operations that are not memory-safe in the Prelude. So, I think, we need at least a standard library for the FFI. (In the FFI spec, we after all went to a lot of trouble to realise as much as possible of the needed functionality as libraries, to change the core language as little as possible.) I understand the desire to cut down on the number of library functions defined in the report, but ultimately, the language needs to provide a basic set of functionality that is the basis for implementing all the other libraries. Otherwise, the usefulness of the standard gets undermined. Apart from the Prelude, I think we should ask the following question to decide whether we can omit some library functionality from the language definition: If we omit the functionality under consideration, can we implement it in a portable manner with what remains in the definition? If that is not the case, we ought to include it. Manuel PS: As a historical anecdote, it was a major shortcoming of Modula-2 over C that Modula-2 didn't define it's basic libraries properly with the language (whereas C did). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Sat, Jul 11, 2009 at 08:54:14PM +1000, Manuel M T Chakravarty wrote: Ross Paterson: The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move to the Prelude when the non-library part of the FFI spec is incorporated into the Report? If we have these types in the Prelude, the associated functions should be in the Prelude, too, and I'd be reluctant to include operations that are not memory-safe in the Prelude. So, I think, we need at least a standard library for the FFI. (In the FFI spec, we after all went to a lot of trouble to realise as much as possible of the needed functionality as libraries, to change the core language as little as possible.) The difference is that the types are used by the core language definition (section 3.2 of the FFI Addendum), and the functions aren't. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On 08/07/2009 22:45, Ian Lynagh wrote: On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Sounds good to me. See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 Ian, would you like to take ownership for this proposal, and start fleshing out the details in a wiki page? There seems to be support for removing all the libraries in the report. Whether the report also blesses either the Haskell Platform or a set of packages is a separate matter; either way, we still have to extract the existing libraries from the report, and there will be a set of changes to the report necessary to make that happen. The Report should explicitly list all the library entities that it refers to. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
Simon Marlow: On 08/07/2009 22:45, Ian Lynagh wrote: On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Sounds good to me. See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 Ian, would you like to take ownership for this proposal, and start fleshing out the details in a wiki page? There seems to be support for removing all the libraries in the report. Whether the report also blesses either the Haskell Platform or a set of packages is a separate matter; either way, we still have to extract the existing libraries from the report, and there will be a set of changes to the report necessary to make that happen. The Report should explicitly list all the library entities that it refers to. I don't mind defining libraries separately, but not defining them at all is problematic unless a core set of libraries isn't rigorously defined somewhere else. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On 09/07/2009 13:26, Bulat Ziganshin wrote: Hello Simon, Thursday, July 9, 2009, 3:46:31 PM, you wrote: This would be a bold step, in that we would be effectively standardising a lot more libraries than the current language standard. The base package is a fairly random bag of library modules, for instance. It The base library is under the question, but remaining libs of ghc/HP are in rather good shape of course, without base we can't do even i/o, so questions still remains. in particular, you plan to do something with base in 6.12 although it was not yet decided what exactly so these two discussions (what to do with libs in 6.12 and what to do with libs in Report) may go together ideally, we would split base into smaller and versionable packages. at least in form of interfaces, while implementations will just import everything from base I feel this discussion is widening a bit too far. The question at hand is how to make the Haskell 2010 Report self-consistent, avoid confusing users, and avoid perpetuating obsolete libraries. The Haskell Report doesn't have to specify libraries, it is not supposed to be a complete specification of the Haskell universe, it is a specification of the language. Remember that we're talking here about a *standard*. The Haskell Platform libraries, while being a hugely useful resource, are not specified to the level of precision we would expect for a Haskell standard. Neither have they undergone the level of scrutiny that we would ideally subject libraries to. So we can't just throw all this stuff in the standard and say done!. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Haskell 2010: libraries
On Thu, Jul 9, 2009 at 5:15 AM, Brandon S. Allbery KF8NHallb...@ece.cmu.edu wrote: On Jul 8, 2009, at 17:55 , Bulat Ziganshin wrote: On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. instead, ghc bundled libs say it, replaced now by Haskell Platform libs. but these are de-facto standards, and i think that Report should support it by defining the same set as standard de-jure Perhaps the real answer is that the Report should bless the Haskell Platform - not any specific version of it. It occurs to me that the dependency might actually go the other way: a Haskell Platform release specifies which versions of the Haskell standard it complies with. (Including H98.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH I agree with this. The goal of the HP is that users are able to say this package works with HP version X. The Platform should be the central compatibility point, and it should specify the version of the language used in the platform. I think there is an advantage to having just one compatibility layer to track (i.e. the Platform). If the Report specified a version of the Platform, but the Report were only offered half as often as the Platform, then we would get a weird situation with some HP releases being report-blessed and some not included in the report at all. Alex ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Haskell 2010: libraries
This is more of a consistency issue than anything else. We have to decide what to do with the libraries in the Report. Right now, the Haskell Report specifies 15 library modules. Things like Maybe, Char, IO, Time, and Random. The situation is not ideal, for many reasons: - There are a lot more than 15 library modules available to Haskell programmers! The libraries section of the report was a good idea when there were no libraries at all, nowadays it makes a lot less sense. - These modules are using the old non-hierarchical names. Best practice these days is to use the hierarchical versions. - some of these libraries have well-known problems, and some have been superseded by better libraries: Time is a good example. On the other hand, some people like having these modules around, and deliberately use them because they aren't allowed to change. I'm mainly concerned with projecting a consistent picture in the Report, so as not to mislead or confuse people. Here are the options I can see: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary. 2. Just drop the obvious candidates (Time, Random, CPUTime, Locale, Complex?), leaving the others. 3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. Also it would seem slightly strange to have a seemingly random set of library modules in the report. 4. Combine 2 and 3: drop some, rename the rest. 5. Don't do anything. Note that we have to take into account the FFI libraries too: the FFI addendum includes modules such as Foreign, CForeign, Storable, MarshalError, and so on. The same issues apply: the report needs to mention some of the types and entities exported by these modules. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Please keep discussion focussed: this is about how libraries are presented in the Haskell report, not about library standardisation in general. I'm aware there are much wider issues, but we have some immediate problems to address. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Isaac, Wednesday, July 8, 2009, 11:05:44 PM, you wrote: It could be a mere informative reference: the most-community-accepted libraries at the time of publication are:. no, i mean that if we include some library in Haskell-2010, then it means that any compiler declared as H2010-compliant, is obliged to support this library of this exact version final goal is to allow someone to get code and compiler both meeting the same Haskell-20XX standard and be able to use the later on the former for sure. it's because we want to provide some base for learning Haskell, and, it will be great - for its industrial usage too this not necessarily should be bare compiler, but may be some compiler-based distribution like that existing Haskell Platform does for GHC -- 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
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Sounds good to me. See also http://hackage.haskell.org/trac/haskell-prime/ticket/118 Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
