Re: Guile foreign object interface

[David Kastrup]

Thien-Thi Nguyen <address@hidden> writes:

> () David Kastrup <address@hidden>
> () 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