Parallel installability, API stability

[Ludovic Courtès]

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
>> (http://lists.gnu.org/archive/html/guile-devel/2003-02/msg00074.html).

[...]

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

Agreed.

[...]

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

Thanks,
Ludo’.