From: Dale Mellor <dale@dmellor.dabsol.co.uk>
Subject: Re: First look at Guile Std Library available
Date: Sun, 4 Jan 2004 15:17:05 +0100 [thread overview]
Message-ID: <16376.8289.572500.721543@l.a> (raw)
In-Reply-To: <16376.5782.10995.206284@l.a>
>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@surf.glug.org> writes:
Thien-Thi> from lurking on the emacs-devel mailing list, i've come to
Thien-Thi> understand the word "coherence" in an application context... in a
Thien-Thi> library context, what kind of integration are we talking about?
Thien-Thi> if integration is actually not what you mean, could you explain
Thien-Thi> how would "coherence of the whole library" be measured?
IMHO, in this case, coherence = efficiency, and efficiency is defined as the
ratio of satiated user's expectations over lines of code to implement. In other
words, a good library is one that meets a lot of people's needs without imposing
a massive maintainence burden on the library maintainer (which in turn delivers
reliability).
Thien-Thi> here are two decisions you can make early on:
Thien-Thi> (a) what is the policy re proliferation of work-alike (but not
Thien-Thi> exactly identical) interfaces? one-size-fits-all vs
Thien-Thi> pluralistic-menu...
Thien-Thi> (b) what is the policy for changing an interface wrt backwards
Thien-Thi> compatibility?
Thien-Thi> IME as a "user" of programming languages, tools, and employees,
Thien-Thi> useful trumps standard trumps efficient. in practice, efficiency
Thien-Thi> is such a fuzzy concept, it is often measured in terms of
Thien-Thi> usefulness!
IMHO, we should be looking at a well designed one-size-fits-all interface
approach (otherwise it will never be documented properly, and will be a slur
against the purity of the scheme programming language). We should use three-part
version numbers, and within a major version release there should be complete
backwards compatibility among minor version changes (there may be localized
compatibility breakages amongst micro versions as interfaces are worked out and
stabilized). If one day it transpires that a wrong turn was made and a new
direction is needed, then the major version should be incremented, and a new
namespace (std-2, say) be introduced, ***but the older (std) namespace should be
kept in the library so as not to break any existing code***.
Dale
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2004-01-04 14:17 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
[not found] ` <16376.5782.10995.206284@l.a>
2004-01-04 14:17 ` Dale Mellor [this message]
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=16376.8289.572500.721543@l.a \
--to=dale@dmellor.dabsol.co.uk \
/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).