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 toa. 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. Wealready need to add some syntax to allow a package to depend on multipleversions 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 downsideis it's quite general: people can do it anywhere and can easily get incompatible collections of types. For example base:Prelude.Int wouldonly be the same as haskell2010:Prelude.Int because it is explicitly setup 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 pointof view they just list the package dependencies as usual and get thesensible overlapping order. Presumably packages not designed to be usedin 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 university KF8NH
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
