[Top][All Lists]

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

Re: First look at Guile Std Library available

From: Dale Mellor
Subject: Re: First look at Guile Std Library available
Date: Mon, 5 Jan 2004 11:08:21 +0100

>>>>> "Andreas" == Andreas Rottmann <address@hidden> writes:

    Andreas> Richard Todd <address@hidden> writes:
    >> 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.
    Andreas> Hmm, I always kind of disliked that approach.

    Andreas> 1) It's probably very hard for a standard library (which presumably
    Andreas> consists of lots of modules) to stay API-compatible over an longer
    Andreas> period of time. Consider the GNOME project -- they have the concept
    Andreas> of the "GNOME developer platform", which will, given a constant
    Andreas> *minor* release number stay API compatible, but may (and mostly
    Andreas> will) break API every minor release number change, which happens
    Andreas> about every six months.

    There is a big difference between the Guile stdlib and GNOME. GNOME is a
tight-knit community of advanced developers (for the most part, anyway), whereas
the Guile lib has to appeal to and be used by complete novices (people who only
pick the language up because it is used in the configuration of another program,
for example). The Guile lib is much more like C++ STL than libgnome. It has to
set the standard for people to use, and keep it. You cannot expect every
developer of a Guile script to keep step with API changes. Breaking API every
six months is, simply, not acceptable for the Guile lib.

    Andreas> 2) Presumed the need for API-breaking changes are needed, in turn
    Andreas> not to hinder development of the library itself, in intervals quite
    Andreas> smaller than 5 years, it would be more of a annoyance to developers
    Andreas> regularly adapting to the API changes (which indeed should only be
    Andreas> "major" in the sense that they require a lot of adaption to
    Andreas> existing code accross major version changes) to require changing
    Andreas> all their code to use stdY instead of stdX.

    They don't have to change all of their code to stdY if stdX remains

    >> 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?
    Andreas> I just skimmed a bit over your code, and it seems quite OK. A few
    Andreas> bits I've noticed:

    I'm sorry I'm making blind comments without yet having looked at your
code. I keep meaning to do it but am having difficulty making the
space. However, I think the question of the approach to design is much more
important right now than the implementation details.


reply via email to

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