Module Considerations

[Jim Blandy <jimb@red-bean.com>]

>Wow - you believe that (for example) every "Emacs Lisp package rewritten
>in, or translated to, Guile" will come with its own configure script?
>In fact, keeping a Guile-based Emacs up-to-date is the situation I was
>worried about when I made my suggestion - a maze of twisty little packages,
>all different ...

Well, every package distributed independently of Emacs that is
big enough to care about such issues, yes.  All the GNU packages
have configure scripts, right?

I think the vision of a bunch of packages, each knowing which
revisions of other packages they require, is nice.  But I'm not sure
version numbers actually work well enough to be worth the trouble.

Revision numbers are defined too loosely to be helpful.  Instead,
let's number "interfaces": an interface is a set of functions that
take certain arguments, and fulfill certain behavioral contracts with
their users.  By specifying an interface number, a module's user
specifies what behavior it expects from the module.

There are two kinds of changes one can make to an interface: backward
compatible changes, and incompatible changes.  Both require the
implementor to increment the interface number.  So in effect, a module
implements a range of interfaces --- from the oldest iface it's
backward-compatible with, to the newest one it implements.  Users
specify what interface they need, a single number.

I write a module A that provides functions make-table, table-ref,
table-define!, and table-map.  That's interface 1.

I add a function table-undefine!.  That's interface 2, since I added a
function, but the module still supports interface 1.  So I mark it as
supporting interfaces 1 -- 2.

Now I reverse the order of the arguments to table-map.  That's
interface 3.  Since I no longer support interfaces 1 -- 2, I mark the
module as supporting just interface 3.

But suppose a given user doesn't use table-map.  Now it'll decide it
can't run on the latest release of the table module, when it actually
could.

The autoconf approach has two chief beauties:
1) It only checks things the user actually cares about, so the above 
   problem won't arise.
2) It doesn't require any help from the module's author, who can't
   predict what users will care about.  Have you ever tried to install
   a new imake-based package on a system with an older version of
   imake?

In short: I think version numbers probably won't help much.  I could
be wrong.  I wouldn't be opposed to some experimentation.