[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:
(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.
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).
(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.
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
- Re: First look at Guile Std Library available, (continued)
Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/03
- Re: First look at Guile Std Library available, Nic Ferrier, 2004/01/03
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/03
- Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/03
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/04
- Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/04
- Message not available
- Re: First look at Guile Std Library available, Dale Mellor, 2004/01/04
- Re: First look at Guile Std Library available,
Richard Todd <=
- Re: First look at Guile Std Library available, Andreas Rottmann, 2004/01/04
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/05
- Re: First look at Guile Std Library available, Robert Uhl, 2004/01/05
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/05
- Re: First look at Guile Std Library available, Robert Uhl, 2004/01/05
- number->string radix patch (Was Re: First look at Guile Std Library available), Richard Todd, 2004/01/06
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Robert Uhl, 2004/01/07
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Richard Todd, 2004/01/07
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Robert Uhl, 2004/01/07
- I get unknown immediate error in guile 1.7, Roland Orre, 2004/01/08