Re: displayLilyMusic -- tested

[Nicolas Sceaux]

Han-Wen Nienhuys <address@hidden> writes:

> some comments.

They're welcome.

> * Couldn't the print-method be added as a property to
>   scm/define-music-types.scm for each type? (or perhaps as a list of
>   methods?)

Good idea.

> * I think it is better to call the routines xxx-display-yyy
>   iso. xxx-print-yyy, to prevent any confusion between front-end and
>   backend.

OK.

> * If possible, the meta-machinery for printing and the actual methods
>   should be in different files, the latter file being called
>   define-music-display-methods.scm

OK. I've let all in one file so that you find all the material in a
single place, but that was my plan to split the library part and the
actual data.

> * I notice that you mention GOOPS in a comment. We do use goops in a
>   couple of places, but we should minimize this. I do not want
>   LilyPond to be completely dependent on GUILE. It would be nice if we
>   could switch to a different scheme interpreter with a relatively
>   small amount of work. (specifically, I'm considering MzScheme for
>   this.)

OK (I don't really like GOOPS). Choosing Scheme and trying not to depend
on a specific implementation is dooming you to often reinvent the wheel,
as the part that all Scheme implementations have in common (the Scheme
spec + srfi) is very tiny. But anyway, switching from guile to any other
implementation that provides a compiler seems to be a good idea!
That's not the first time that you express your will to switch scheme
implementation; please consider that I'm willing to help you on that
task when you are decided. (that seems a really huge task nonetheless).

I'll work on a new version of display lily music, integrating your
suggestions.

nicolas