Process issues (was Re: Lang)

[Malcolm Wallace]

> 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.

Ok, I acknowledge that.  I think we seem to be gradually coming to
a consensus on Marcin's point - that the functionality of a library
should be paramount in the naming scheme, regardless of implementation,
standardness, portability, etc.  This is good.

> 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).

This seems reasonable in principle.  There are quite a few attributes
of each library module that we need to know, quite separate from the
actual name and source code.  Again, it begs the question of how this
meta-information will be maintained.  One common database for all
Haskell compilers/interpreters would be ideal.

Sounds like about the right size for a small student project actually....
Has anyone got any small students?  :-)

Regards,
    Malcolm