Han-Wen Nienhuys <[EMAIL PROTECTED]> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
