Lang. (was Re: Alternative hierarchy proposal)

[Malcolm Wallace]

Marcin 'Qrczak' Kowalczyk wrote:

> Also tools for manipulating the language sources are very different
> from language support modules. They should not be put together;

I think this further supports my point that the name "Lang" is
ambiguous.

But I really have no idea what a "language support module" might be.
Why does the language need support?  In a sense, don't /all/ libraries
"support" the language, simply by providing useful abstractions?
If the term "language support module" means something more specific,
then what exactly?  Does it mean that the module requires extra support
/not/ found in the standard language?  If so, then "language support"
is misleading - you really mean "beyond-the-language support", or
in simple terms "extensions".

> Instead, tools for manipulating our language (parsers, typecheckers
> etc.) should be together with tools for manulpulating other languages,
> and language-independent tools.

Well, yes I could agree with this.  Maybe the Haskell language should
have a special "privileged" status amongst the many languages we want
to manipulate, simply because we are talking about the Haskell library
structure itself?  But maybe not.  I don't mind too much.

> BTW. I'm working on a Haskell<->Python binding. Where should it go?

    Haskell.Plus.Foreign.Python

by analogy with

    Haskell.Plus.Foreign.C

or maybe just

    Haskell.Plus.Python
    Haskell.Plus.C

or indeed, how about

    Language.Python
    Language.C
    Language.Haskell

?  It depends to some extent on what you want to do with the foreign
language.  Are you writing a foreign function interface, or are you
writing tools to manipulate Python source code + abstract syntax?
Should we have different hierarchies for these two different kinds
of library?

Regards,
    Malcolm