Malcolm Wallace writes:

One abbreviation I have always disliked intensely though is Lang. [snip]

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

Haskell Plus Foreign Generics Dynamic Language AbstractSyntax Parse PrettyPrint

Here in my scheme, Haskell.Plus contains extensions to the language, 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 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