Re: First look at Guile Std Library available

[Richard Todd]

(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