[Haskell-cafe] Re: Interest in helping w/ Haskell standard

Cale Gibbard cgibbard at gmail.com
Sat Oct 15 02:17:33 EDT 2005

On 15/10/05, Ketil Malde <ketil+haskell at ii.uib.no> wrote:
> David Roundy <droundy at abridgegame.org> writes:
> >> Bah, simple libraries.  They don't have to be part of the Standard
> >> Prelude.
> > I completely agree.  I'd rather decrease the number of libraries defined in
> > the language itself and decouple library standardization from the
> > definition of the language standard.  Libraries can much more easily be
> > developed and improved.
> I'd vote for moving map, null and lookup from Prelude to an explicit
> List import (like insert already is).  They tend to be used by
> collections (Data.Set, Map etc), which complicates imports or requires
> unnecessary qualification.
> Alternatively, as (List.)map and null are very common, use different
> names for other collections (fmap? isEmpty?).
> As a general rule, I think libraries shouldn't overload names imported
> implicitly from the Prelude.  (I know it is fashionable to qualify
> everything this week, but I prefer to be able to use unqualified names
> occasionally as well).
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants

Or fix the "Set is not an instance of Functor" problem and then rename
fmap to map. :)  John Hughes' proposal works, though I don't know if
I'd like all the wft's cluttering up my class contexts.  I've been
thinking of some other ways to solve the problem by extending the kind
system (as the problem is that the kind of the type parameter to Set
should not really be *, but a subkind thereof consisting of the types
satisfying Ord).  It looks like this approach should work, but I
either need to do more reading or more talking to people knowledgeable
about type theory, and the existing implementations in order to
completely formalise it.

I agree somewhat about the qualified names, but I think in a lot of
cases, when things are called the same thing, it is because they are
doing the same thing, and so there should be a typeclass for them.

 - Cale

More information about the Haskell-Cafe mailing list