On 2010-04-02, Ian Hulin wrote: > > 3. There's a restriction introduced in Guile V2.0 whereby dynamic > use of define, define-public and variants will cause the guile > compilation to fail with diagnostics. We have these in our basic > Scheme files (lily.scm and lily-library.scm). These compilation > failures currently stop Lilypond building altogether.
This is really just a stricter adherence to the Scheme R5RS. (if ...) can only contain *expressions*, IIUC, and (define ...) is a top-level definition, not an expression. But yes, either LilyPond will need to adapt to these stricter guidelines, or Guile will loosen its policy with respect to (if ...) statements. > 4. We've already seen the %module-public-interface thing in the Lily > C++. There's probably more smelly stuff lurking in the C++ > interface, which won't surface until we start trying to use Guile > 2.0 more. I think almost everything is fixed on the C++ side now. > Graham, Vincent, is it worth opening a tracker to capture > forward-compatibility issues with Guile? We already have one (sort of): http://code.google.com/p/lilypond/issues/detail?id=963 > Thanks for your feedback so far, Ludo. The other Lily developer who > has done anything with Guile 1.9/V2.0 is Patrick McCarty > (pno...@gmail.com). That's <pnor...@gmail.com>. I don't want any email reaching the wrong mailbox. :-) -Patrick
