Re: Guile 3.0

[Jonas Hahnfeld]

On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> So at the cost of rocking the cage a bit hard, I came asking the
> uncomfortable question:
> what would happen if (for this unique circumstance) we'd do what one
> would normally consider poor practice?

Let's call your proposal by its true, scary name: we would essentially
*fork* Guile and, in the longer term, make it fit exactly what we need
for LilyPond. This has a bunch of implications, one of which is that we
take on the burden of maintaining that forked version. If you don't
believe that will cause problems, I would just like to remind you that
Guile 1.8 was fundamentally incompatible with 64-bit Windows. Nobody
can foresee what will be the next problem; maybe there are none but I
would doubt it; but any time spent on the maintenance of a fork is
already too much in my eyes for a community that is comparably small.

The second implication is that we get technologically stuck. As bad as
the current situation is, it has given incentive to move on. For
example, I'm thinking of Han-Wen's work on the structure of output
backends that was originally meant to reduce the penalty with Guile 2.2
but in the end resulted in a net improvement overall. And after
dropping support Guile 1.8 (and lots of related code!), Jean is already
making good use of some of the new constructs. There are probably other
parts that work around deficiencies in Guile 1.8 which could be cleaned
up now (just search for "crazy bug" in scm/output-lib.scm).

With all that said, I think there are good reasons why things are
considered bad practice. Similar discussions have already taken place
before, and I'm not sure if we're adding value by repeating them. Maybe
we can come back to the original topic of this thread?

Jonas

signature.asc
Description: This is a digitally signed message part