Re: guilev1/2 musing

[David Kastrup]

Paul Morris <address@hidden> writes:

> On 1/24/19 3:08 PM, Thomas Morley wrote:
>
>>  From my point of view (and limited knowledge) other newly implemented
>> guilev2-procedures are not _that_ important.
>
> One area where guile2 (and upcoming guile3) would be useful is for
> MusicXML export.  David Garfinkle's summer of code project (mentored
> by David Kastrup) made a start on using guile2's sxml and pattern
> matching procedures (which aren't in guile1)

They exist as Guile1 library, it's just that they are by default in
Guile2.  If we decided prepackaging Guile1 was the way to go, including
the respective library version should be feasible as well.

No guarantees, but that was my impression.

> to convert LilyPond's internal music data structures into MusicXML
> output.

> Since guile2 appears to work well enough at this point, aside from
> performance, would it be worth setting up a "guile2 and musicxml
> export" branch where we could land David Garfinkle's code and enable
> further work on MusicXML export?  It seems like a guile2 branch
> already exists to some extent?

Not really, and I don't think it makes sense to commit functionality to
Guile2-only at this moment.

> Then at some future point... either LilyPond moves to a future guile
> or we back-port the guile2 procedures to guile1.

"some future point" is just going to cause additional work.  We don't
really have the personnel to do non-essential/non-trivial work on two
separate implementations.

> (Jan-Peter Voigt has also done separate work on MusicXML export, but
> my sense is that in the long run, the approach in the summer of code
> project would be preferable.)

I haven't looked at Jan-Peter's approach.  David Garfinkle's code is
mostly in the state of a solid first sketch, so a distribution-viable
production-ready code is still quite a bit of work away.  Without
anybody committed to take it considerably further, making decisions
based on its existence would seem to be a bit premature.  Like with many
open ends, this is more or less the "who decides to invest significant
work gets to decide on the approach".  There is not much of a point in
planning out in detail what nobody will pick up.

> Thanks for the insights into the guile1/2 situation and what's causing
> the performance hit.

-- 
David Kastrup