guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: features, modules and packages


From: Thien-Thi Nguyen
Subject: Re: features, modules and packages
Date: Thu, 27 Dec 2001 00:31:33 -0500

   From: Alex Shinn <address@hidden>
   Date: 27 Dec 2001 11:20:29 +0900

   [...] but if you encourage programmers to write in terms of features
   you're going to get the same thing.

good point, if taken to an extreme:

   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.

ok, what version of guile is installed on the system now?  does it
support `identity' or not?  can any published libguile api other than
the source be trusted?  is the available source the source of the
system's installed libguile (and ice-9 and whatever other crap makes up
my environment)?  this user in particular loathes keeping track of these
kinds of things.

   The real feature list of a module is it's API, with all the procs it
   exports and all the behaviour therein.

i'm glad to see people trusting others to uphold high engineering
standards, although the dark side of the force, when your vendor changes
things and doesn't document them properly, is powerful, too.  changes
can include: reformatting, munging stuff that's not even used (by you),
documentation changes with/without code changes, API upgrade, downgrade,
sidegrade, etc.  trusting a version number (or any other name) requires
trust for the entire chain of possible engineering best-practices
deviance.

   I don't want something that provides spewutils-like functionality,
   because then I need to put conditional logic in my code.

nobody is asking you to change your code.  besides, srfi 0 handles this.

   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.

i'm afraid you're letting the "configuration" concept scope-creep to
runtime, for which these points are more suited.

the proposed system allows for trust, anyway:

   AC_GUILE_MODULE_REQUIRED(ttn spewutils)

is this so onerous?

thi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]