Arne Babenhauserheide <arne_...@web.de> writes: > David Kastrup <d...@gnu.org> writes: > >> Arne Babenhauserheide <arne_...@web.de> writes: >>> PS: Just saying "it’s a scripting language now" will not cut it. >> >> With an implied "rather than an extension language": that _would_ cut >> it. It would imply LilyPond having to work with a fork of Guile-1.8, >> and possibly encourage active maintenance of such a fork independently >> of LilyPond. It would also put a clear perspective on Emacs-Guile's >> future, namely none. > > It would also show that Guile leaves people behind who choose it.
We are talking about Free Software here. Its programmers and maintainers are the ones who have to find the energy to take it places. An entity "Guile" that would be able to assign resources does not really exist. My personal impression is that the goals and distribution of the energy right now does not really scale to match the goals that Guile has been selected for with respect of its intended and announced roles in the GNU project a long time ago. That's unfortunate, but a mismatch of hopes and expectations, even _announced_ hopes and expectations with what actually turns out to be possible given finite resources and inspiration, is not malice. > Yes, it would be a strategy, but not one which inspires much > confidence in the longterm stability of its goals. "longterm stability of goals" is a mixed blessing. The world changes. Guile 2.0 is not as stable as Guile 1.8 was for use, but the version numbers don't suggest differently. I was not involved with LilyPond when it still worked with Guile versions like 1.4: I assume that was quite more strenuous. There is no really established and comfortable migration path from Guile-1.8 to Guile-2.x but there is not a large corpus of applications that would make working on such a path in general rewarding or even worthwhile. So it is natural that projects are "left behind" as default and one needs to find the best way to help them over into the future with explicit and manual effort. With larger adoption of Guile, the choices and options here might have looked differently. > I did not mean it as option in Lilypond. I meant it as strategic > possibility. As I see it, it's not big enough that strategic guarantees can be given. If you need guarantees, you need to invest into the resources needed for that. >> The C++ part [of LilyPond] is structured to fit in with Guile. But >> this sort of 1:1 relation is much more tenuous with Guile-2 since the >> interaction costs have become quite larger. So it works better for >> either applications that have just a little Guile, or for >> applications that have little else. > > I hope that will change again. I’m sure most people here want Lilypond > to be faster with Guile 2.x than with Guile 1.8. Where is "here"? It would look better, for sure. -- David Kastrup
