[Top][All Lists]

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

Re: First look at Guile Std Library available

From: Richard Todd
Subject: Re: First look at Guile Std Library available
Date: Sun, 04 Jan 2004 15:51:17 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

(writing from my windows machine, so not set up to gpg sign it, but it's me I promise!)

Thien-Thi Nguyen wrote:
here are two decisions you can make early on:

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,

I thought that's what I was trying to ask in my post, via the examples I gave. I'm looking for input on what the community wants, and (more importantly) would help contribute to. I don't want to go this alone, and in fact I think it would be ridiculous to generate a 'standard' library in isolation!

I don't follow why one-size-fits-all would reduce the immediate usefulness of the libarary for some users. Are you are talking about a user who was already using an interface from another library that I incorporated and changed? Compared to the benefit to new users who would not be faced with several disjoint interfaces, I think this is insignificant (especially since they can keep on using the old lib if they want).

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.

I agree with Dale Mellor's response. It's standard practice to stay compatible along minor version numbers, and OK to break backwards compatibility across major version numbers. This code base should grow over time, and the ideal organization and interface to the modules will certainly shift, even if we do get it perfect in the first place (which we won't, of course).

What do you think of (std ...) => (std2 ...) as a means of letting older code run forever? I've read c++ is considering this approach. I don't think it should happen but every 5 years or so, and only then if backwards compatibility has become a burden.

As for 'supremely careful', this is why I have released work so early, and plan for all of us working on the project to do the same. I want the time between now and June to be the period where people attempt to use and criticize what's out there. Anything that is still controversial will be left out of the first release.

I'm a little disappointed that all the response I've gotten has been about the library concept, and no one has yet appeared to be interested in the code I've put out there to date. Do you like it? Hate it? Don't care about it? Can it be that only Java/Python/Perl/Ruby need logging services, and scheme does not?

> 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.

Again, yes, figuring that stuff out would help, and that's why I brought it up. I'm looking for input. Much of your post seems to be re-asking the same questions I was asking.

I can answer these questions on my own (and I think I mostly have done so by way of releasing code that has a certain slant to it), but I am trying to get a feel for what others think is best for guile. I think we all at least agree that having _something_ is desireable.

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 am trying to start a project, but it's not about me, or being the only service. It's a question of whether we want a bundle or a framework.

I have said, and do believe, that it would be good to have a single library that provides the baseline infrastructure for doing useful work. Would everyone be satisfied if we grouped 6 packages and made sure they all 'configure && make install' properly, or do people want something more than that? I was imagining they would want more, but now would be the best time to find out I'm wrong about that.

Where are the other such services, anyway?

 > 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!

Regardless of which trumps which, what is 'useful', 'standard', *OR* 'efficient' about what a guile user has today? When I download the JDK I have a ton of 'useful', 'standard', *AND* 'efficient' components from which I can start useful work. There is no comparison, even if you start with (+ guile ice-9 slib).

I've had a serious suggestion that I redirect this effort to SLIB, and I'm mulling that over. I would have to make serious changes, since I've been freely using guile-specific code so far (such as goops classes). I'm also not thrilled with the way slib is organized, but there would be some benefits to going that way. We could still produce a (use-modules) interface to the entire SLIB library, which I think makes sense in any case. Any thoughts?

Richard Todd

reply via email to

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