Simon Marlow wrote:
I disagree. Lang (or Language if you like, or HaskellLanguageFeatures) is a *semantic* category. It contains libraries which provide access to language features.
Are you saying that there are language features which cannot be accessed without these libraries?
but in most cases it's obvious what belongs in Lang, and that's the main thing.
That's just the trouble: I don't find the contents of Lang to be obvious at all. I simply don't see the semantic relationship between the various modules. If I, as a Haskell language implementor, have difficulty understanding it, I'm sure other people will too.
Ok, it was wrong to assume that because it was obvious to me it was also obvious to everyone else :-) I'll try an alternative. How about this: - Foreign moves to the top level, - Array moves to Data.Structures.Array (Lang was the wrong place for it, on reflection). I'm not sure where to put the rest of the contents of Lang, it seems to me that we need somewhere to put libraries that provide access to, or support for, language features that don't belong in Data. For example: Exceptions, Monads, Dynamic, etc. Where do these go in your proposal?
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".
Well, I disagree completely. I proposed "Haskell." precisely because it /is/ a semantic category, in contrast to "Lang." But that's just my view. Both you and Marcin don't see the connection, so I'll happily retract that part of my layout proposal, and search for an even better categorisation.
Sorry, that comment was a bit blunt (it was Monday morning :). I'll try to be more specific: the trouble is that the Haskell.Plus hierarchy doesn't group libraries by functionality, it groups them by status (language extensions). And Haskell.Language doesn't have anything in common with Haskell.Plus functionality-wise.
I understand. I'm even beginning to shift my point of view towards yours. But there remains a difficulty. What if two people develop similar extensions, but with different syntax/semantics, each in a different compiler?
Either: - neither library gets in until they agree a common interface, or - both libraries get in, with different names so that we can experiment with them before deciding on a unified interface. Like Pretty.HugesPJ, Pretty.UU etc. I'd rather wait until we've pinned down the hierarchy before discussing the process for accepting new libraries, but I guess to a certain extent the issues are interrelated. Briefly, what I had in mind is: each module in the hierarchy has a status, ranging from experimental to standard. The closer to "standard", the less likely the interface is to change. The hierarchy as a whole would need a version number, so that applications can conditionally compile code for changing libraries if they need to. In addition to standard/experimental there needs to be portable/non-portable for libraries that depend on or provide language extensions. A "standard" library would only be able to depend on certain extensions (eg. FFI and module-namespace only). Cheers, Simon