On 11/07/2009 11:54, Manuel M T Chakravarty wrote:
Ross Paterson:
On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
There will be some loose ends where the rest of the report
refers to entities from these libraries, e.g. the Prelude
refers to Rational from the Ratio library. We just have to
fix up these references, moving the appropriate definitions
into the Report as necessary.
Some of the loose ends:
The defaulting rules (section 4.3.4) apply to any class "defined in the
Prelude or a standard library". The non-Prelude classes involved are
Ix and Random.
The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16,
Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move
to the Prelude when the non-library part of the FFI spec is incorporated
into the Report?
If we have these types in the Prelude, the associated functions should
be in the Prelude, too, and I'd be reluctant to include operations that
are not memory-safe in the Prelude. So, I think, we need at least a
standard library for the FFI. (In the FFI spec, we after all went to a
lot of trouble to realise as much as possible of the needed
functionality as libraries, to change the core language as little as
possible.)
The functions don't necessarily have to be in the Prelude too - the
point of putting the types there is so that we can specify what a valid
foreign import/export declaration is.
I understand the desire to cut down on the number of library functions
defined in the report, but ultimately, the language needs to provide a
basic set of functionality that is the basis for implementing all the
other libraries. Otherwise, the usefulness of the standard gets undermined.
The usefulness of the standard is already undermined by specifying a set
of libraries that we don't recommend people use, and that differ in
confusing ways from the libraries that we do recommend people use (e.g.
they have different names, such as CForeign vs. Foreign.C).
I'm all for having standard libraries, but we have to think about what
we can practically accomplish for Haskell 2010.
Apart from the Prelude, I think we should ask the following question to
decide whether we can omit some library functionality from the language
definition:
If we omit the functionality under consideration,
can we implement it in a portable manner with what remains in the
definition?
If that is not the case, we ought to include it.
I don't like to think of this in terms of "omitting functionality from
the language definition". It's more a case of deferring the
standardisation of libraries in the Report, until such time as we can
produce a polished library standard. The functionality is still there,
in the implementations, well documented, and in the FFI spec. It is
also explicitly versioned in the Haskell Platform, so language
implementers can all agree on what to provide.
To use the above test would mean we could avoid specifying some
libraries but not others, based on some criteria that is not important
to users. I don't think this is the right way to approach the problem.
Some libraries inevitably have non-portable implementations: e.g.
Data.Typeable, Control.Exception, Data.IORef. We would be able to leave
out Data.List, but not Foreign.StablePtr. Which is more useful?
Another option (option (3) in my original mail) is to rename all the FFI
libraries to use the hierarchical names and include them in the Report.
But what other libraries should we include? I favour this approach
slightly less than just leaving out all the libraries, mainly because
the result would be an fairly arbitrary collection of library modules,
which is of limited use to both users and language implementers. It may
serve as a start for a larger collection of standard libraries; however,
it would also be quite a lot of work to get this done for Haskell 2010.
PS: As a historical anecdote, it was a major shortcoming of Modula-2
over C that Modula-2 didn't define it's basic libraries properly with
the language (whereas C did).
I completely agree there should be standard libraries. But I don't
think that should prevent us from producing a language revision in the
short term.
Cheers,
Simon
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
