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