On Thu, Mar 08, 2001 at 08:24:26PM +0000, Malcolm Wallace wrote:

Simon Marlow wrote:

...

Here's my attempt at a library hierarchy. No ASCII art

Just to let everyone know that Simon's proposed tree is now on the web alongside mine. See:

http://www.cs.york.ac.uk/fp/libraries/

Ermmm, OK, so what now? What we currently seem to have seems rather akin to the Bit(s) situation this is meant to avoid :-) Anyway, here are my opinions and an attempt to merge the two together. Flames^WComments welcome. Here is a list of common top level hierarchies: Data Database Debug Graphics Haskell Network Numeric Posix Text Data Database Debug Graphics Lang Net Numeric Posix Text Personally I prefer the latter list, and as I've said before I think POSIX would be better split up. In MW: * Algebra Seems fair enough * Interface Not sure about the name of this - contains GetOpt and Readline GetOpt might belong better under parsing somewhere and ReadLine in IO? Having just noticed them on SM, they are next to IO under System. * Win32 Dunno what would go in here. Possibly OS.Win32 or something would be better regardless to kep the top level branches to a minimum? In SM: * System THis is equivalent to Haskell.Plus.Unsafe I think. Personally I think this is a good idea as it is not implementable in Haskell. I'm not sure the Plus distinction is necessary though. * Source This appears to be parsers etc for Haskell code, and I don't see why it should be here rather than Text.Haskell next to HTML, XML etc * Concurrent I don't know anything about this but it looks fair enough * Parallel As the comment is "as hslibs/concurrent/Parallel" should it not go under Concurrent? * Prelude MW has Haskell.Language.CoreSyntax which I think makes more sense * GHC Probably better under Lang.CompilerSpecific.GHC? There's also the Std vs Non-std top branch debate. I agree with the non-std myself. The SM trees in general seem a bit better thought out to me too, e.g. I don't think Bits or MD5 belong under Data.Encoding. To summarise I think something like: Algebra: As MW Concurrent: As SM plus Parallel Data: As SM Database: As SM and MW Debug: As SM and MW Graphics: As MW (more detailed than SM) Lang: As SM, plus CompilerSpecific.*, Prelude, { System.* from SM plus POSIX plus BSD } Net: As SM (plus a POSIX module if POSIX talks about this) Numeric: As SM and MW OSSpecific: As explained Text: As SM and MW User: your@email.address gets address.email.your.* off of this BTW, the first bit of Data is repeated twice on the SM list Thanks Ian -- Ian Lynagh - http://c93.keble.ox.ac.uk/~ian/haskell/

Sat, 10 Mar 2001 12:24:13 +0000, Malcolm Wallace pisze:

Here in my scheme, Haskell.Plus contains extensions to the language, and Haskell.Language contains utilities to manipulate the source language itself.

I must say that I haven't guessed what Haskell.Plus means until I saw it explained. It is not clear. Also tools for manipulating the language sources are very different from language support modules. They should not be put together; it's a coincidence that they could be put under the title "Haskell". Instead, tools for manipulating our language (parsers, typecheckers etc.) should be together with tools for manulpulating other languages, and language-independent tools. BTW. I'm working on a Haskell<->Python binding. Where should it go? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

Sat, 10 Mar 2001 18:05:43 +0000, Malcolm Wallace pisze:

But I really have no idea what a "language support module" might be.

Functionality which is hardwired in the implementation, not definable portably and efficiently, exposed as a plain module. Doesn't matter if it's standard. For example IO, Array, StablePtr, Dynamic, Observe. OK, probably it should not matter for the programmer how much magic it requires to be implemented, so modules should be named basing only on the subject they are about. A tree structure, especially without aliases, doesn't work well if there are several criteria for naming things, e.g. * what kind of functionality (e.g. a HTML parser, a database interface), * conforming to what standards (e.g. Haskell 98, Posix, BSD, ghc's / nhc98's extension), * what magic it requires to be implemented (pure Haskell wrapper, needs heavy runtime system support), * where did it come from, i.e. author's / company's name. For users the first category is the most important. For implementers all except the first. I would try to use the first category as much as possible, and only make differences wrt. other categories deeper in the tree if needed. For example let's put Posix filesystem functions and BSD symlink support near Directory, Readline near Curses and hypothetical WinConsole, don't make a subtree for Haskell 98 modules, and don't expect independent vendors to put their modules in their own subtrees. If it's natural that one of several modules will be chosen basing on portability switches, it's a sign to put them together.

Haskell.Plus.Foreign.Python

Ugh, sorry, I can't stand Haskell.Plus. Every module changes Haskell-without-that-module into Haskell-plus-that-module!

Are you writing a foreign function interface, or are you writing tools to manipulate Python source code + abstract syntax?

A foreign function interface.

Should we have different hierarchies for these two different kinds of library?

I'm not sure. In interpreted languages they are blurred. In compiled languages there is a clear distinction: either it works on sources (e.g. generates documentation) or interoperates with live compiled modules. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

On Sat, Mar 10, 2001 at 02:23:05PM +0000, Marcin 'Qrczak' Kowalczyk wrote:

Sat, 10 Mar 2001 12:24:13 +0000, Malcolm Wallace pisze:

...

Here in my scheme, Haskell.Plus contains extensions to the language, and Haskell.Language contains utilities to manipulate the source language itself.

I must say that I haven't guessed what Haskell.Plus means until I saw it explained. It is not clear.

I agree. I think Haskell.Extensions is far clearer.

Also tools for manipulating the language sources are very different from language support modules. They should not be put together; it's a coincidence that they could be put under the title "Haskell".

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

Again agreed, as I've said elsewhere. Ian -- Ian Lynagh - http://c93.keble.ox.ac.uk/~ian/haskell/