Haskell 2010: libraries
malcolm.wallace at cs.york.ac.uk
Tue Jul 14 04:27:22 EDT 2009
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
> It'd be nice to have a clear dividing line of keeping the pure stuff
> 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
More information about the Haskell-prime