This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Module Considerations


>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes:

Lee> In addition, a standard module versioning method should be available
Lee> which will allow one module to require that another module be "at
Lee> least version 'N.M' or later" and/or "no later than version N+n.M+m",
Lee> and to declare its own version for use by the same require mechanism.

Jim> This is an interesting idea.  I've also noticed the problems you
Jim> describe.
Jim>
Jim> But the way (it seemed to me) interfaces actually evolve is anything
Jim> but linear.  Years ago I concocted an astonishingly complex system for
Jim> version numbers which reflected this.  Then I had a series of
Jim> nightmares about COBOL ENVIRONMENT declarations, and dropped the
Jim> subject.

Gag.  What I had in mind would be far from the final solution; it
should be sufficiently flexible to adapt to the real needs of module
developers and users once the system has some air time.  Members of
this list don't seem to be shy about giving honest feedback.  :-)

Jim> It seems to me that configure scripts can grovel around, check for
Jim> bindings and features, and decide for themselves whether to warn the
Jim> user.

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

-- 
Lee Thomas    lee_thomas@credence.com   (503)-520-6551
Senior Software Quality Engineer
Credence Systems Corporation, Beaverton, OR, USA