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
Hello Simon, Friday, April 30, 2010, 1:42:33 PM, you wrote:
During the Haskell 2010 process the committee agreed that the libraries in the report should be updated,
i think: if committee assignment turned out to be ambiguous, it should be returned to committee. we can discuss it here but then committee should make a clear decision -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
During the Haskell 2010 process the committee agreed that the libraries in the report should be updated,
i think: if committee assignment turned out to be ambiguous, it should be returned to committee. we can discuss it here but then committee should make a clear decision
The committee's decision is clear enough. The question is to do with implementation issues that are not specified by the Report. Regards, Malcolm
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
When you talk about the package "haskell2010" do you mean a package named "haskell" with major version "2010" as in "haskell-2010" or a package actually named "haskell2010"? Regards, Bas
On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace
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
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
On 30/04/10 13:19, Malcolm Wallace wrote:
4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties.
In many ways this corresponds to my preferred solution, although I would rephrase it thus:
* Deprecate use of the "base" package, (I do not mean to remove "base", just to freeze it, and discourage its general use.) * Create a new "haskell2010" package (for ghc this will be built on topcommon of "base", but other compilers might make a different choice). * Create a new "portablebase" package which contains (or re-exports) all of the remaining useful and portable parts of the current "base" _and_ "haskell2010". * Create a new "ghcextras" package which re-exports (or defines afresh) all of the useful but non-portable parts of the current "base".
So it seems this is closer to option (2) in my message, because portablebase and haskell2010 overlap, and are therefore mutually exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping - that's the crucial difference. I described this as a non-option because I thought trying to use the packages together might be a common problem that leads to obscure error messages about ambiguous modules, but perhaps it's not that bad, or at least not worse than the other solutions. I think we can leave the question of whether to abstract the existing base into separate "portablebase" and "ghcextras" packages as a separate issue - there are merits to doing something like this for sure, but I'd like to focus specifically on Haskell 2010, and I think portablebase/ghcextras are orthogonal.
Because I suggest that "portablebase" re-export the "haskell2010" API in its entirety, it would be impossible to use both packages explicitly at the same time from a single module - users would need to choose one or the other. Also, packages which currently depend on "base" should be encouraged to upgrade to a dependency on "haskell2010" rather than on "portablebase", if possible, because it provides greater stability of interface.
We hope in the future that the set of libraries standardised in the report grows beyond what we have in base currently, so I'm not sure how much sense it makes for portablebase to re-export the haskell20xx modules. Generally speaking we've been tyring to make base smaller rather than larger. Indeed right now there are some modules in the report that aren't in base, although those are the ones we're considering removing in this iteration. I like the picture where we have a small base, lots of independent packages, and one or more haskell20xx packages that re-exports all the standardised stuff from the other packages. This arrangement extends smoothly, the only problem is that haskell20xx overlaps with the other packages.
5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries.
This seems superficially attractive, but I think it would be impossible in practice to guarantee anything. For instance, the semantics of "take" and "drop" changed between Haskell 1.4 and Haskell'98 iirc, with no corresponding change in the API. With separate packages it is possible to retain and choose between both sets of semantics.
Yes, I agree - that's a non starter. Cheers, Simon
On 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
On 01/05/10 17:16, Ian Lynagh wrote:
So it seems this is closer to option (2) in my message, because portablebase and haskell2010 overlap, and are therefore mutually exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping - that's the crucial difference.
If they are non-overlapping, how would a new Data.List function be added? Or an existing Data.List function be altered?
In this scenario there would be base as it is now, and base2010 (or whatever you want to call it) that is base minus the modules in haskell2010. So you can add things to base:Data.List, but haskell2010:Data.List must export exactly the API as specified in the report.
No matter what solution is chosen, changes to datatypes or classes seem likely to be troublesome.
Yes, that's true. Adding methods to classes is possible, but adding constructors to datatypes, or new instances, is not.
I think the library change plans are underdeveloped, the libraries should be unchanged in H2010, and we should resolve this issue before changing them in a future language revision. That would keep other options open, such as the report standardising Haskell2011.Data.List rather than Data.List, etc.
FWIW, I omitted mentioning that option because I think it's the worst of the bunch :-) I think that putting version numbers into module names is a very dangerous thing to start doing. When you want to upgrade your code to Haskell 2011, you have to change not just the .cabal file but all the imports too. Keeping version dependencies collected together in one place and not scattered through source code is one of the better design decisions we made, I believe. Doing "nothing" as you suggest is an option, but it would mean using the non-hierarchical names for the FFI libraries. There's nothing technically wrong with it, but I find it a bit odd to be standardising modules with names that in practice almost no code has ever used. I suppose those are the names in the FFI addendum though.
I described this as a non-option because I thought trying to use the packages together might be a common problem that leads to obscure error messages about ambiguous modules, but perhaps it's not that bad, or at least not worse than the other solutions.
Direct imports of base* and haskell* could be (dis)allowed by the implementation depending on whether it is in "Haskell 2010 mode" or not.
Not sure what you mean here - modules are imported, not packages. Type error! It's the modules that overlap between the two packages that are the problem. If someone imports Data.List, do they mean the haskell2010 or the base one? If you're suggesting that we choose based on whether the flag -fhaskell2010 is set, then that really amounts to the haskell2010 package shadowing base when -fhaskell2010 is on. It might be the right thing, but it's a slightly ugly special case.
We hope in the future that the set of libraries standardised in the report grows beyond what we have in base currently
Oh, I thought the plan was for library standardisation in the report to be reduced, with perhaps the Haskell Platform becoming the new library standardisation effort.
I thought the *eventual* plan was to properly standardise lots of libraries, with the Haskell Platform being an intermediate step on the way to standardisation. Though I don't think we ever actually decided anything, really. Cheers, Simon
On 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
On 01/05/10 20:17, Ian Lynagh wrote:
On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:
On 01/05/10 17:16, Ian Lynagh wrote:
So it seems this is closer to option (2) in my message, because portablebase and haskell2010 overlap, and are therefore mutually exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping - that's the crucial difference.
If they are non-overlapping, how would a new Data.List function be added? Or an existing Data.List function be altered?
In this scenario there would be base as it is now, and base2010 (or whatever you want to call it) that is base minus the modules in haskell2010. So you can add things to base:Data.List, but haskell2010:Data.List must export exactly the API as specified in the report.
So someone using haskell2010+base2010 wouldn't be able to use this new function?
Correct. If you opt to use the Haskell 2010 API, you don't get to see new additions made to those modules, but that's entirely reasonable. Cheers, Simon
On May 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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
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
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
On May 4, 2010, at 05:09 , Duncan Coutts wrote:
On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
Bear in mind these goals: we want to
a. support writing code that is Haskell 2010 only: it only uses Haskell 2010 language features and modules.
b. not break existing code as far as possible
I'm going to dissent here: current code assumes extensions, not a standard. I think it's not outside the pale to have code that wishes to conform to Haskell2010 be modified to do so, and otherwise the code continues to be "extended nonstandard Haskell" if it is not already Haskell98-conformant. After all, Haskell2010 doesn't quite include *all* of the extensions that are in common use. So, I'm going to go out on a limb here and suggest that Haskell 2010 code should specify
{-# LANGUAGE Haskell2010 #-}
to distinguish from Haskell '98 code (no LANGUAGE pragmas) and extension code (other LANGUAGE pragmas). Users who wish to combine the above with nonstandard extensions can expect to do extra work. Existing code continues to work because it doesn't explicitly limit itself to Haskell2010. A side benefit of this is that it requires the code (not a cabal file or etc.) to specify that it is Haskell2010 as opposed to Haskell98 or etc. Unless cabal-install is a mandatory part of Haskell2010, relying on it to specify the language support level strikes me as not the best of ideas.
If people think the order in the .cabal file is not sufficiently explicit then I'm sure we can concoct some more explicit syntax. We already need to add some syntax to allow a package to depend on multiple versions of a single dependency.
We already have most of that, don't we? There's the extension to allow you to specify the exact package to use for a given module; with "as" syntax one might presumably say something like
import "haskell-2010" Data.List import "containers-ext" Data.List as L;
I understand this may require some work, but it seems a reasonable extension of existing syntax. It also puts the onus of making things work together on the user, and (as mentioned above) I think that's eminently sensible for existing code that assumes that it uses extensions, not a standard.
The advantage of the client doing it is it's quite general. The downside is it's quite general: people can do it anywhere and can easily get incompatible collections of types. For example base:Prelude.Int would only be the same as haskell2010:Prelude.Int because it is explicitly set up to be that way. Arbitrary shadowing would not be so co-operative.
ghc already lets you do this by rebinding syntax. What happens if you rebind (>>=) in a way that isn't quite compatible with the monad laws? Granted, right now you have to do fairly esoteric stuff to get yourself into that kind of trouble, whereas we're talking now about something likely to be more common.
I'm not quite sure how it would be implemented but from the user's point of view they just list the package dependencies as usual and get the sensible overlapping order. Presumably packages not designed to be used in an overlapping way should still give an error message.
The problem here is, how do you know? I recall suggesting some time back that dependencies without an upper bound were going to be a problem, and lo and behold, when base-4 came out they broke. If a package declares itself to be capable of overlapping, does it apply only to Haskell2010 or is it assumed to also apply to Haskell2011 unless specified otherwise? Or do we try to figure it out automatically? (Which I suspect would cause all sorts of problems.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (9)
-
Bas van Dijk -
Brandon S. Allbery KF8NH -
Bulat Ziganshin -
Christian Maeder -
David Menendez -
Duncan Coutts -
Ian Lynagh -
Malcolm Wallace -
Simon Marlow