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
