Hi again! Andy Wingo <wi...@pobox.com> writes:
> On Tue 20 Oct 2009 10:27, l...@gnu.org (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’.
