Re: features, modules and packages

[Thien-Thi Nguyen]

   From: Alex Shinn <address@hidden>
   Date: 27 Dec 2001 15:51:30 +0900

   [module availability equivalent to feature]

so what's wrong with:

AC_GUILE_MODULE_AVAILABLE(mod_curses,(ncurses ncurses))

?  i fail to see an argument here.

   ["core" features; better to use simply the module name]
   optionally with a version number.

ok, here's a specialization for you (untested):

# REQUIRE_GUMM_MODULE(name,version)
# - name is a list of symbols, like: (ice-9 common-list)
# - version is some gumm-conformant token that doesn't include ","
#
AC_DEFUN([REQUIRE_GUMM_MODULE]
         [AC_GUILE_MODULE_CHECK(req_gumm,$1,
             (lambda () (gumm-version-check "$1" "$2")),
             availability and version)
          if test "$req_gumm" = "no" ; then
              AC_MSG_ERROR([required gumm module not found: $1 $2])
          fi
         ])

now you figure out how to virtualize AC_GUILE_MODULE_CHECK interpreter
to support this properly, or i'll do the task eventually...

   Well, yes, it is entirely a matter of trust, that's the whole point.

the whole point includes trust and distrust.  ahab, et al.

   And, no, you're not supposed to expect others to uphold high
   engineering standards.  That's why you can refer to exact versions,
   in case they change something down the road.  It actually works out
   worse with casual features, because people aren't going to define a
   new feature for every little change.  Suppose you start writing a
   module frodo, based on another module bilbo, and you release frodo
   depending on the feature ring-bearer.  You later upgrade your
   installation of bilbo, and start working more with it, using more
   procs that may or may not have been in the earlier version.  When you
   make your next release of frodo, gumm users may update it and the
   gumm script won't know to also install the newer version of bilbo
   because the dependency hasn't changed.

???  sorry, i can't in my present state figure out this paragraph.  i
feel that there is the "quality" of something, which (according to
pirsig) is actually its moment of perception by the perceiver.  this
quality can be described by others, but only the perceiver understands
it truly from the exact point of view of the perceiver (almost by
definition).

when describing a quality, it is like telling a story, or sharing code.

the abstractions decorate reality
beautiful in their own right
villany lurks in the shadows, only

   Features are good for a process like the srfi's, but that's because they
   *are* expected to uphold high engineering standards.  But it is a very
   slow process done by committee.  If you want to build up a friendly
   community of people sharing code, it has to be more informal.

the most informal is already in place.  people are friendly already.

i think if you are able to distinguish the thing from labels of the
thing, you will see that "feature" and "version" have the same feel,
which explains my puzzlement at why you're not expressing your ideas in
code, instead of ignoring the general tools recently posted.  maybe
you're confusing "featuretest" with "feature" and having an emacs
triggered reaction -- we all succumb to that at some point.  please get
well soon.

   But the next most important thing after having this system available
   is having lots of modules, so we want to make the process of creating
   modules and working out dependencies as simple as possible.

i hope the above REQUIRE_GUMM_MODULE gets you started...

   Rather than requiring the other module author to factor out his
   changes into some feature definition, it's much easier to just make
   your module dependent on the new version.

this is the crux of your discomfort, but luckily, no one is requiring
module authors to do anything except write normal modules (and publish
them).  however, it sounds like you're requiring module authors to
reliably sync a (module-specific?) version number w/ whatever edits they
are making.  tsk tsk.

   rather than

     AC_GUILE_MODULE_REQUIRED(ttn spewutils feature)

where do you get this syntax from?  please look at the comments above
the AC_DEFUNs i've posted, and let's move on to other discussion, or
more gumm implementation.  the problem has been solved generally (for
scheme modules, anyway ;-).  next for me is to add to aclocal/guile.m4
these ideas (first virtualizing "guile -s", unless someone beats me to
it).

a nice thing to do would be to use some of this configuration machinery
at runtime (or at "sysadmin-munge-system time"), as you point out.  i'll
catch up to you someday, maybe next week. :->

thi