[Top][All Lists]

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

Parallel installability, API stability

From: Ludovic Courtès
Subject: Parallel installability, API stability
Date: Wed, 21 Oct 2009 18:45:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hi again!

Andy Wingo <address@hidden> writes:

> On Tue 20 Oct 2009 10:27, address@hidden (Ludovic Courtès) writes:


>> I think we must pay close attention to backwards compatibility, at least
>> to honor long time promises
>> (


> For that reason we also think that Guile should be parallel-installable,
> at least on the library level. That means that we should have the
> version in the library name, and the version in the include path; so
> pkg-config --cflags guile-2.0 will say e.g. -I/usr/include/guile-2.0,
> and that pkg-config --libs guile-2.0 will be e.g. -lguile-2-0, or
> something.



> Sure, we need to make well-thought-out changes -- but our current
> policy of very extended C-level compatibility is very, very limiting,
> and a big energy drain. If we think we need to change a function
> interface, well, we just change it, and document the change as well --
> perhaps even with a Coccinelle[0] patch.

I’d probably be more conservative than you on API changes.  For
instance, I think ‘scm_search_path()’ and ‘scm_primitive_load()’ should
be the same in 1.8 and 2.0 (at least at the C level, because in Scheme
it’s easy to retain compatibility with optional args.)

Guile is a niche, and so is Scheme.  Among those who develop
applications using Guile, I bet the vast majority does it on their free
time.  Free time is scarce and better spent writing application code
than upgrading to the latest APIs.  Thus, I think Guile core should
evolve hands in hands with its users, making, indeed, only
well-thought-out API changes.

Actually, all GNU libraries I can think of, as well as Emacs, follow
this scheme.  I don’t think this is pure coincidence.  GTK+, Python,
etc. can afford disruptive changes, but their “ecosystem” is much


reply via email to

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