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
