Lang. (was Re: Alternative hierarchy proposal)

[Marcin 'Qrczak' Kowalczyk]

Sat, 10 Mar 2001 18:05:43 +0000, Malcolm Wallace <malcolm@abbess.demon.co.uk> 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