Thien-Thi Nguyen <t...@gnu.org> writes: > () David Kastrup <d...@gnu.org> > () Thu, 09 Mar 2017 00:00:48 +0100 > > [...] rather than [...] fork Guile 1.8 in order to actually > have some dependable functionality to base other work on. > > I intend to maintain 1.8 for the time being. More precisely, i > seek to apply bug fixes, improve documentation (both method and > content), modernize the build system (tracking gnulib, autotools > evolution), and (time and gumption permitting) refactor some > internals. If the gods smile, maybe a feature or two (always w/ > an eye on upward compatibility). > > If the changes to 1.8 that Lilypond requires fall into the above > categories, perhaps we can avoid a fork. Do you have a summary > of those changes handy?
The changes to 1.8 that LilyPond requires is that Guile-1.8 needs to be compilable with newer compiler versions and standards and that distributions are confident enough about it to keep distributing it. That's all: LilyPond works fine with Guile-1.8 as it is. Yes, migrating to some sort of UTF-8 capable string scheme transcending the "byte array" approach of Guile-1 would be nice but the Guile-2 approach would likely be a major performance hog and it does not make sense for a Guile-1.8 fork to develop a different approach: any such "different approach" fork should, if at all, focus on the Guile-2 code base as a starting point. Unless there is an approach that is so lightweight that it just fits better when starting with the Guile-1.8 code base. But all in all the most important thing LilyPond would want from Guile-1.8 is not to die. -- David Kastrup
