Re: guilev1/2 musing

[Paul Morris]

On 1/25/19 10:43 AM, David Kastrup wrote:

> Paul Morris <address@hidden> writes:
> > 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.


Ah, good to know they exist as guile1 libraries.  (I just assumed that 
since guile2 was used for the gsoc project, that they didn't exist for 
guile1.)

Does anyone know where to locate them?  I did some searching and came up 
short.  They are "Pattern Matching (ice-9 match)" and "SXML" modules in 
the current guile2: 
https://www.gnu.org/software/guile/manual/html_node/Guile-Modules.html


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


Okay, and since the needed libraries exist for guile1, then work on 
(that approach to) musicxml export doesn't need to be blocked waiting on 
guile2.

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

Makes sense, and sounds like we don't need to wait for guile2 anyway.

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


Indeed, although, I've contributed a bit to Jan-Peter's code for this, 
and would like to contribute more (as time allows) to see this feature 
added to LilyPond.  But I've wondered which approach would make more 
sense for eventual landing in LilyPond.  More consensus about the 
approach, could encourage contributions by removing such questions.

Cheers,
-Paul