Lang. (was Re: Alternative hierarchy proposal)

Simon Marlow simonmar@microsoft.com
Fri, 23 Mar 2001 15:48:52 -0000


> Simon Marlow wrote:
>=20
> > I must admit, I'm not keen on the name "Control" - it's=20
> meaning isn't
> > clear in the context of Haskell, and it sounds forced. =20
> Let's face it,
> > we're trying to find a unifying concept for a mixed bag of abstract
> > libraries, and there just isn't one.
>=20
> Doesn't that very fact suggest that these libraries should /not/ be
> grouped together?

Perhaps, but who knows what abstract language concepts/features the
Haskell community is going to come up with next?  I'm keen to make sure
that we're likely to have a good home for anything that comes along in
the future.

> > FWIW, I just took a poll of the 4 people in our office=20
> (inc. me) and the
> > vote came out unanimously in favour of calling it "Lang".
>=20
> And our office (of 2) continues to have a unanimously opposite view...
>=20
> So if these libraries really don't belong together, as you admit, we
> need to find alternative homes for them.  Here's one suggestion:
>=20
>     Monad       ->  Data.Structures.Monad

debatable, but I could live with it.

>     Exception   ->  System.Control.Exception

ew.  System currently contains libraries that communicate with the
outside world and the "system" on which the program is running.  It's a
stretch of the imagination to put Exception in this category.

>     Generics    ->  Type.Generics

hmm. Generics is more about generic code than types.

>     Dynamic     ->  Type.Dynamic

ok.  but if we have a Type category, folk might expect to find types in
there: i.e. everything we have in Data.

>     Unique      ->  Data.Structures.Unique

fine.

>     Concurrent  ->  System.Control.Concurrent
>     Parallel    ->  System.Control.Parallel

dubious, for the same reasons as Exception.

All these choices leave me with a slightly uneasy feeling, as if we're
trying too hard to categorise things that don't fit into a particular
category.  Concurrency and exceptions aren't "system"-y things, in my
mind they're nothing more than language features. =20

Ok, so eventually we'd like to have a proper "home" for everything
currently in the Prelude, right?  Then the Prelude is just a convenient
set of entities which are commonly used and therefore deemed useful to
have in scope by default.  Most things in the Prelude have a logical
home: eg. all the numeric classes go in Num, basic data types in Data,
IO in System.IO, etc.  The following are left:  Eq, Ord, seq, error,
($!), undefined, flip, (.), and a few others.  Where do they go?  Eq is
neither Control nor Data, and doesn't seem to fit anywhere else in the
hierarchy.

For comparison, Java has "lang", but not "data".  The documentatation
describes "lang" as "Provides classes that are fundamental to the design
of the Java programming language.", which is suitably ambiguous.

Cheers,
	Simon

PS. I took a poll of the office next door (i.e. Simon P.J.), and he
suggested "Control" or "Effects".