[Prev][Next][Index][Thread]
Re: A basic question: defining modules and libraries
In article <Pine.GSO.3.96.1000328164553.23489F-100000@tardis.tardis.ed.ac.uk>,
Hugh Greene <q@tardis.ed.ac.uk> wrote:
>Yes, you don't want to have to group more functionality into a library
>just for optimsation's sake. Modules are the unit of interface, libraries
>are the unit of *compilation*.
This discussion makes it obvious that we don't have a good definition of
what a library is. I don't agree with Hugh that they are the unit of
compilation -- it's easy to envisage an implementation (or a mode) in
which definitions are the unit of compilation, and the language shouldn't
prevent this. Dylan's designers may have intended libraries to be the unit
of compilation, but this suggests a pre-existing notion of libraries, which
they chose to be the unit of compilation, rather than a definition of
libraries per se.
Nor are libraries necessarily the unit of delivery -- as others have
pointed out, we might package several libraries into a single DLL. They
aren't the (primary) unit of namespace; that's the role of modules.
Nonetheless, there clearly is some concept here. Every programmer has
encountered this in some form or another. E.g., although ML has nested
modules, the SML/NJ implementation has a notion of libraries, and Harlequin's
old MLWorks compiler has a notion of project. Both these concepts group
bunches of modules together, map them to files, include compilation options,
etc. Even the simplest C environment includes Makefiles.
Dave.
References: