New libraries process
wren ng thornton
wren at freegeek.org
Fri May 27 05:39:39 CEST 2011
On 5/26/11 5:22 AM, Christian Maeder wrote:
> Am 26.05.2011 09:37, schrieb Simon Peyton-Jones:
>> Friends
>>
>> Thanks to those who responded to the message below, about improving
>> the process for developing the core Haskell libraries.
>> http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
>
> I see:
>
> "Portability. Good code is portable. In particular, try to ensure the
> code runs in Hugs and GHC, and on Windows and Linux."
>
> I believe Hugs is dead and Mac OS is also an important platform, so
> apart from testing on multiple platforms (automatically by "validate"?)
> I wonder what a good portability measure is. Maybe older versus most
> recent ghc versions, or as few extensions (that just ghc support) as
> possible (ideally none?).
While Hugs is dead, claiming Hugs portability does still serve a useful
purpose IMO. In particular, the most recent Hugs is roughly
contemporaneous with GHC 6.6, which captures an important point in the
development of the type system. In particular, Hugs supports functional
dependencies, MPTCs, and overloadable instances. This collection of
features is relatively easy to implement[1] and served as the de-facto
"standard Haskell" for a long time. While the revived Haskell committee
hasn't yet blessed all these extensions, they are the sort of things
that people expect of any "complete" Haskell compiler. Last time I
checked, JHC and UHC haven't quite made it to that benchmark yet (though
hopefully that'll be changing soon, if it hasn't already).
After the GHC 6.6--6.8 era, the development of the type system began
moving quickly again. Whereas this classic Haskell was focused on
extensions to the typeclass system, newer GHC is focused on dependent
type issues like GADTs, type families, etc. Because this newer work is
still very much in flux and has much deeper consequences for the whole
type system than does the typeclass stuff, there are good reasons for
not expecting non-GHC compilers to follow it all, and for wanting core
libraries to avoid using the extensions in order to retain portability.
Saying that the code is portable to Hugs seems like a reasonable
circumlocution for expressing all of this. Unfortunately, because of the
death of Hugs, it really is a circumlocution. Though as I recall, there
are some folks still *using* Hugs for embedded devices even though
development and maintinence of the interpreter has ceased. For those
folks, knowing that core libraries are still compatible is a nice thing.
[1] The exception being fundeps which are notoriously difficult to
implement correctly.
--
Live well,
~wren
More information about the Libraries
mailing list