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
