> 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
