[Top][All Lists]

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

Re: Mark procedures, LilyPond, and backward compatibility

From: Andy Wingo
Subject: Re: Mark procedures, LilyPond, and backward compatibility
Date: Thu, 05 Nov 2015 15:46:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Hi :)

I appreciate what you say.  I do think that we are mixing topics a bit.
Regarding the future applicability of the foreign object API to precise
and moving GC -- this can be added.  I have worked with precise and
moving GC systems.  During the time that I hacked on SpiderMonkey, it
moved from a conservative to a precise moving GC.  It's possible to do,
though I think it is naive to consider doing so without any action
required on the part of a libguile API user.  Specifically I would have
the foreign object type be annotated with a descriptor of its fields.
I do not want to add it now, however; it is too premature IMO.

I hope that clarifies some points.  I am happy to keep the discussion
going :)

I am top-posting though because I think there's a general message in
your mail, that we made wrong decisions in the past and that we should
feel bad about them for some reason in the present.  I strenuously
disagree.  We did the best that we could with the knowledge we had.  I
don't even admit to the mistakes, I don't think -- I mean, if I were
there and did it again, I would most certainly adopt the BDW-GC and
psyntax.  No question.  I would have done different things around
finalizers and mark procedures, but we were ignorant; postulating
retroactive omniscience doesn't help us make better decisions in the

I also disagree very strongly that we are being irresponsible with
respect to backward compatibility.  We're doing what we can, and doing
much more than most other projects.  To me it is especially galling to
hear this, after having been practically the only developer working on

I also think you underestimate the abilities to change -- both of Guile
and of our users.  The important thing is that existing interfaces keep
their semantics, and that we help users identify when those interfaces
need to be removed for whatever reason, and what to do.  In the lilypond
case we had trouble maintaining the semantics.  Maybe now that we know
about it we can fix it.  We do what we can.

Dunno where I'm going with this, so I'll just stop here :)  Happy
hacking :)  Let's pick up the foreign object discussion in another


On Wed 04 Nov 2015 18:01, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>> At the end of our IRC conversation yesterday you put the burden on me to
>> argue against mark procedures, which was fair, but at this point I think
>> we would need good arguments for keeping them,
> The most important reason that we need to preserve mark procedures is
> that we've supported them for most of Guile's existence, and there's a
> lot of important code out there that depends upon them.
> Remember LilyPond?  As much as we might like to forget that LilyPond
> exists and move onward with more fun things, the fact remains that as
> you prepare a 2.1.x pre-release, LilyPond still doesn't work with Guile
> 2.0.x, and not for lack of effort.  This problem is not just going to go
> away.  We _must_ help to get LilyPond working, and we must *not* take more
> steps that would make that job more difficult.
> We must demonstrate that Guile is a safe base upon which to build a
> large application.  LilyPond is by far the most important project that
> has done that, and the ongoing LilyPond+Guile2 disaster is a glaring
> example that "mistakes were made" in the 1.8 -> 2.0 transition.  I think
> we need to acknowledge those mistakes, learn from them, and pay more
> attention to backward compatibility now and in the future.
> What mistakes were made?  Among many other things: Guile 2.0 switched to
> a new macro expander that doesn't support lazy macro expansion, and to a
> GC with very different finalization semantics.
> LilyPond has a lot of code that depends on the semantics of our old GC.
> For starters, it depends heavily upon our long-standing support for mark
> procedures, and will surely require ongoing support for a non-threaded
> marking mode as well.
> While we're on the subject: <> demonstrated
> that Boehm GC will invoke marking procedures on objects that have
> already been finalized.  It seems likely that fixing LilyPond will
> require adding support to Boehm GC for another kind of finalizer with
> semantics similar to the finalizers in Guile 1.8, where the finalizers
> were strictly called before the mutator resumes execution.
>> I think it makes sense to *avoid* adding mark functions to the new
>> APIs, at least for now.  We don't have the use cases right now and so
>> we would surely specify the wrong thing.  We can always add something
>> later.
> In summary, if we're going to deprecate and replace an existing API, the
> new API needs to be designed such that it's straightforward to update
> existing code to use the new API.  Therefore, we must continue to
> support mark procedures.  I would go further and assert that the new API
> should also include what's needed to support a precise, moving GC.  To
> do otherwise would be to strongly encourage the creation of code that
> cannot possibly work with a moving GC.
> Deprecating and replacing the SMOB API is a significant event in the
> history of Guile.  It should not be rushed, nor should it be finalized
> until it supports existing use cases and anticipated future
> developments.
> As an aside, I'm not happy with the fact that this new foreign objects
> API was pushed to the stable-2.0 branch less than 25 hours after the
> initial proposal was posted.  It feels like establishing "facts on the
> ground", and sets up a situation where the burden is now on me to argue
> that it's not ready to be included in 2.0.12, whereas the burden should
> rather be on you to obtain a consensus that this new major API is ready
> for release.
> For now, I would prefer to revert the commits that added this new API,
> to enable the immediate release of 2.0.12.  Then we can have a proper
> discussion about what a SMOB replacement API should look like, and make
> sure that both past and future anticipated use cases are covered before
> releasing it.
> What do you think?
>       Mark


reply via email to

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