unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@surf.glug.org>
Subject: Re: First look at Guile Std Library available
Date: Sun, 04 Jan 2004 13:59:31 +0100	[thread overview]
Message-ID: <E1Ad7qt-0000hj-00@surf.glug.org> (raw)
In-Reply-To: <20040104035022.GA742@Richard-Todds-Computer.local> (message from Richard Todd on Sat, 3 Jan 2004 21:50:22 -0600)

   From: Richard Todd <richardt@vzavenue.net>
   Date: Sat, 3 Jan 2004 21:50:22 -0600

   I'm trying to think through other options,
   since I think the coherence of the whole library would suffer.

from lurking on the emacs-devel mailing list, i've come to understand
the word "coherence" in an application context (app == emacs) to be
definition 1b from webster's[1], the operative word being "integration".
in a library context, what kind of integration are we talking about?  if
integration is actually not what you mean, could you explain how would
"coherence of the whole library" be measured?

   1) We could include that code too.  [...]
   2) We could make the needed modifications [...]

   The situation can be even more complicated, like if both allow you to
   filter the logs by regexp, but use two different regexp libraries with
   different capabilities.

here are two decisions you can make early on:

(a)
what is the policy re proliferation of work-alike (but not exactly
identical) interfaces?  one-size-fits-all vs pluralistic-menu.  for
the latter, you would probably want to specify "adapter" modules to
reduce interface complexity from NxM to N+M.  for the former, the
proliferation problem is defined away but the immediate usefulness of
the library is reduced for some users, who would be forced to do the
adaptation outside the library (probably in isolation, without
further distribution) -- same boat as the *-pers-scheme approach,
basically.

(b)
what is the policy for changing an interface wrt backwards
compatibility?  if you allow backward-incompatible changes, users
will learn to not trust the library (or at least allocate trust to
those elements that have changed in this way very begrudgingly).  if
you disallow backward-incompatible changes, you need to be supremely
careful when defining interfaces for one-size-fits-all approach,
slightly less careful for pluralistic-menu.

figure out (a) and (b) and a maintenance strategy will probably
present itself naturally.

   Another example would be slib minimize.scm [...]  Or wrap them in
   a third module that re-exports all the methods, and attempt to
   keep the two 'base' madules private?

perhaps figuring out the maintenance axioms can help answer this.
certainly, separating the design of the interface from that of the
implementation allows you some flexibility.

   Another option for the project would be to actively avoid things
   that are already in SLIB, Guile-core, or wherever else, and just
   'fill in the gaps.'  I'm having trouble taking that road, because
   it's asking users to look 5 places for everything they think might
   be available, and deal with all the variations and overlap
   inherent in it.  And, though people may get tired of me waving the
   python standard around, you just don't have this problem with
   other languages.  Sure, there are lots of independent libraries
   out there, but the basics are covered 'out of the box'.

i think it would be a mistake to willfully ignore what is out there,
but that doesn't mean you can't provide a valuable bundling service.
much depends on how you feel about not being the only such service.

   I care, because building an infrastructure that others can build
   on is an important part of making guile useful in the real world.
   If lots of people are out there quietly cobbling together email
   packages out of fragments of people's pet projects, then we are
   not acting in a very efficient manner.

IME as a "user" of programming languages, tools, and employees,
useful trumps standard trumps efficient.  in practice, efficiency is
such a fuzzy concept, it is often measured in terms of usefulness!

thi


______________________________
[1] M-x dict sez:
    Main Entry: co·her·ence # #
    Pronunciation: kO-'hir-&n(t)s, -'her-
    Function: noun
    Date: 1580
    1 : the quality or state of cohering : as a : systematic or
    logical connection or consistency b : integration of diverse
    elements, relationships, or values
    2 : the property of being coherent


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


  reply	other threads:[~2004-01-04 12:59 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-02  5:21 First look at Guile Std Library available Richard Todd
2004-01-02  9:29 ` Dale Mellor
2004-01-03  1:03   ` Richard Todd
2004-01-03  2:25     ` Andreas Rottmann
2004-01-03 15:00       ` Dale Mellor
2004-01-03 14:36     ` Dale Mellor
2004-01-03 22:42       ` Richard Todd
2004-01-03 16:38 ` Thien-Thi Nguyen
2004-01-03 16:48   ` Nic Ferrier
2004-01-03 22:18     ` Richard Todd
2004-01-04  1:49       ` Thien-Thi Nguyen
2004-01-04  3:50         ` Richard Todd
2004-01-04 12:59           ` Thien-Thi Nguyen [this message]
     [not found]             ` <16376.5782.10995.206284@l.a>
2004-01-04 14:17               ` Dale Mellor
2004-01-04 21:51             ` Richard Todd
2004-01-05  0:30               ` Andreas Rottmann
2004-01-05  5:00                 ` Richard Todd
2004-01-05 16:03                   ` Robert Uhl
2004-01-05 20:01                     ` Richard Todd
2004-01-06  1:36                       ` Robert Uhl
2004-01-06 18:41                         ` number->string radix patch (Was Re: First look at Guile Std Library available) Richard Todd
2004-01-07  4:04                           ` Robert Uhl
2004-01-07  5:26                             ` Richard Todd
2004-01-07 20:54                               ` Robert Uhl
2004-01-08  7:11                                 ` I get unknown immediate error in guile 1.7 Roland Orre
2004-01-08 17:14                                   ` Roland Orre
2004-01-10 20:17                                     ` Kevin Ryde
2004-05-10 20:34                           ` number->string radix patch Marius Vollmer
2004-05-11  3:16                             ` Richard Todd
2004-05-11  3:51                             ` Keith Wright
2004-05-27 21:56                               ` Kevin Ryde
2004-06-10 16:35                                 ` Marius Vollmer
2004-06-10 16:34                               ` Marius Vollmer
2004-05-11  5:23                             ` Richard Todd
2004-05-27 21:54                               ` Kevin Ryde
2004-06-10 16:47                               ` Marius Vollmer
2004-06-11  1:40                                 ` Kevin Ryde
2004-01-05 10:08                 ` First look at Guile Std Library available Dale Mellor
2004-01-05  3:39               ` Paul Jarc
2004-01-05  4:28                 ` Richard Todd
2004-01-05  5:19                   ` Paul Jarc
2004-01-06 22:25                   ` Ludovic Courtès
2004-01-06 23:53                     ` Richard Todd
2004-01-16 20:17                   ` Andy Wingo
2004-01-05 14:00               ` Thien-Thi Nguyen
2004-01-05 20:32                 ` Richard Todd
2004-01-05 20:59                   ` Dale P. Smith
2004-01-06 16:54                   ` Thien-Thi Nguyen
2004-01-06 20:32                     ` Richard Todd
2004-01-03 18:19   ` Clinton Ebadi
2004-01-03 20:12     ` Thien-Thi Nguyen
2004-01-04  2:02     ` Richard Todd
2004-01-06 20:42       ` Richard Todd
2004-01-06 21:20         ` Paul Jarc
2004-01-03 22:52   ` Richard Todd
2004-01-04  1:53     ` Thien-Thi Nguyen
2004-01-04 20:34 ` Arno Peters
2004-01-05 20:12   ` Richard Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Ad7qt-0000hj-00@surf.glug.org \
    --to=ttn@surf.glug.org \
    --cc=ttn@glug.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).