Lang. (was Re: Alternative hierarchy proposal)

[Simon Marlow]

Malcolm Wallace writes:
> One abbreviation I have always disliked intensely though is Lang.
> [snip]
>=20
> The other thing that bothers me about Lang is that I don't see the
> connection between many of the things proposed to go into it, and
> the Haskell language itself.  The FFI is the best candidate, because
> it clearly extends the source language.  Likewise, Generics and
> Dynamic.  But why should libraries like Array, Memo, and Monad
> be in Lang?  They don't extend the language.  And of course some
> things /not/ currently in Lang seem to have everything to do with
> the language - like the Haskell source parser, abstract syntax,
> source pretty-printer etc.

I disagree.  Lang (or Language if you like, or HaskellLanguageFeatures)
is a *semantic* category.  It contains libraries which provide access to
language features.  It's not a perfect categorisation (eg. you could
argue that Monads aren't really a language feature, or that Chars are),
but in most cases it's obvious what belongs in Lang, and that's the main
thing.

On the other hand, Haskell in your proposal isn't a semantic category.
The similarity between the contents seems to be in name only:  it's like
saying that "Biography" and "Biology" books belong on the same shelf
because they both begin with "Bio".

> These were the reasons I proposed a hierarchy like
>=20
>     Haskell
>       Plus
>         Foreign
>         Generics
>         Dynamic
>       Language
>         AbstractSyntax
>         Parse
>         PrettyPrint
>=20
> Here in my scheme, Haskell.Plus contains extensions to the language,=20
> and Haskell.Language contains utilities to manipulate the source
> language itself.  Simon proposed Haskell.Source for the latter, which
> would also be a fine name, provided there were no Haskell.Lang
> category to confuse you.

By all means change the name "Lang" to something more mnemonic and
unambiguous, but I like the current meaning (and I have to admit it was
chosen for its similarity to Java and the existing hslibs layout).

> My final difficulty with the Lang category is that, if it contains
> extensions to the language, people will be misled into thinking that
> the extensions are truly a part of the language standard.  After all,
> they are categorised in Lang!  In my opinion, a clearer name=20
> is needed,
> to emphasise the extensional nature of some of the libraries.

I don't agree with separating extensions (as you probably noticed from
my proposal :-).  If we separate language extensions into a separate
hierarchy, code will be broken when/if these extensions become part of
the base language.  Ok so that's probably a long way off, but I don't
feel comfortable with a design which we're accepting will inevitably
change later.

I *do* however believe that extensions should be standardised, so that
if a compiler implements a particular extension, it should match other
implementations of that extension.

You're probably concerned that code which purports to be Haskell 98 will
accidentally make use of non-standard libraries - well for a start, the
extended module namespace is itself an extension, and secondly it will
be easy to restrict the libraries that are available according to
compiler flags: at the moment with GHC, if you don't say -fglasgow-exts
or -package <anything>, then you get Haskell 98.  Full stop.  The
trouble is, Haskell 98 isn't very useful on its own...

Cheers,
	Simon