features, modules and packages

[Alex Shinn]

>>>>> "Thi" == Thien-Thi Nguyen <address@hidden> writes:

    Thi> in any case, autoconf-based methodology encourages thinking
    Thi> about "features" instead of either "package" or "module".  a
    Thi> package or module might only provide one feature, thus its
    Thi> existence on the system could be viewed synonymously, but this
    Thi> is not true generally.  it is also not true that versioning
    Thi> schemes have a universl algorithmic correlation w/ feature set,
    Thi> which is why i'd like to avoid that approach.

Oh dear, please let's not start programming in terms of features instead
of modules, that way lies Emacs (and as much as I love Emacs, I hate it
all the more for the things it did wrong).  Have you looked at
feature-based Emacs programming?  It generally has the form

(and (featurep 'image)
  (cond ((running-xemacs)
         ;; do it the xemacs way
         )
        ((string-match "^GNU" (emacs-version))
         ;; do it the emacs way
         )))

Ok, so it's not the fault of features that there are multiple versions
of Emacs, but if you encourage programmers to write in terms of features
you're going to get the same thing.

When it comes down to it, what the package manager is doing, and what
the user is thinking in terms of, is specific versions of modules.  The
real feature list of a module is it's API, with all the procs it exports
and all the behaviour therein.  When I'm writing a program, I know I'm
going to want (ttn spewutils) as of my currently installed version
(0.28) which has the update-all-pages! function.  I don't want something
that provides spewutils-like functionality, because then I need to put
conditional logic in my code.

Features can be used when you're simply looking for some functionality
and don't have a particular module in mind yet, but then keyword
searches will work as well (and probably better if you don't know what
word was chosen to describe the feature in question).

Probably the only appropriate use for features is for standard,
pre-defined features, such as which aspects of r5rs are available and
which srfi's are supported, because these always behave the same way.
If I know I have the srfi-1 feature, I know I have all the srfi-1
procedures and their behaviour is pre-defined.  But this is mostly
useful for writing cross-scheme scripts - if we want to try the
cross-scheme package manager, we may want to offer a hybrid
feature/module-version based dependency approach.

-- 
Alex