Re: Guile 3.0

[Luca Fascione]

On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:

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


Well, I was not thinking the delta between "true" Guile and "ours" would
ever get big.
If it did, that is what I'd call a fork. And no, I'm _not_ advocating that.

I'm more thinking something along the lines of make 3.81, actually: largely
"mainline",
plus a few small patches to adjust little details. (*)

It's clear that a real fork is not useful here, I agree with you completely

(*) 3.81 is famously incompatible with 3.82, and many large make systems
are stuck in .81 land.
So it's common for folks in that condition to build their own make applying
a few (3? maybe 4) small
patches to fix a few problems with the program instead. Effectively they
run some kind of 3.81+

The second implication is that we get technologically stuck.


Well, the idea is that much like now you'd state a dependency against Guile
2.2.x,
you would then just ship the version you want. I don't see much of a
difference there.
(Again, the key in mind is that the changes from us are a _small_ set, so
the fact that
we would on occasion change the base checkout and reapply the diffs should
be a
small overhead. If you compound this with changed built to maximize the
chances of
eventual adoption, you'd risk eventually getting into a place where these
changes are zero)


> With all that said, I think there are good reasons why things are
> considered bad practice.


There were what felt like good reasons at the time when the practices were
established, yes.

However, as the hypotheses mutate, it can come a point where the
conclusions don't follow any longer.

For example:
one doesn't want to fork because
 - it duplicates code and it's difficult to keep up the two diverged
branches
  -> with RCS _definitely_, with git I'm not so sure. Space cost of
duplication these days is zero. Time taken compiling one more repo, also
zero.
  -> this means that now this part of the reason is reduced to
understanding whether the divergence is large or small

I've seen things that were bad practice when I was a student become
acceptable or recommended now.
I've come to see that "old wisdom" is sometimes not that wise after all
(premature optimization for example,
although in that case that's more an issue of misunderstanding of the
original meaning, than actual change).


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

Forgive me for making poor use of your and the others' time.
I thought this might turn out to be pertinent if it opened up new ways of
thinking about this choice.

L

-- 
Luca Fascione