Mark H Weaver <m...@netris.org> writes: > David Kastrup <d...@gnu.org> writes: > >> When running the following program >> >> (define void 6) >> (use-modules (ice-9 syncase)) >> (define-syntax absurd >> (lambda (x) >> (syntax-case x () >> ((_ var) (syntax var))))) >> >> through Guile 1.8, I get the error >> >> ERROR: Wrong type to apply: 6 >> >> The same appears to go through without problem (apart from the >> deprecation warning for the module) on Guile 2.0. >> >> Is there any workaround? Apart from the obvious "don't define void" >> which is not a good option for the actual application at hand since the >> function is part of a user-level API. And it's not like "void" is >> documented as being anything here... > > However, I looked at the implementation of syntax-case in Guile 1.8.8 > and in short, I think you're stuffed.
Well, ok. I thought this would be a nice thing to use syntax-case for, but it would have been a first in the LilyPond code base (and obviously no users of LilyPond have used anything but procedural macros so far, or we'd have heard complaints). > I'm afraid the best suggestion I can think of is to make your own > local copy of ice-9/syncase.scm and ice-9/psyntax.pp, under different > filenames and module names, to be used only when built with Guile 1.8. Not going to do that. I'll just use something else. And it's conceivable that stuff would work when placed into LilyPond's internals before the user-level "void" is loaded. But it's probably a bad idea for maintenance to use features that cannot sensibly be debugged/tested/used outside of LilyPond's internals since that means no LilyPond users/programmers can become well-acquainted with them. > * Drop support for Guile 1.8 in the first version of LilyPond that > supports Guile 2.0, Guile 2.0 is pretty much ubiquitous by now, so we will not have to support multiple versions. We'll be able to more or less do a hard cut here once Guile 2.0 is supported in an acceptable manner. > so you can clear out the horrible workarounds and compatibility cruft. > > I'm sorry I don't have a better answer for you, and I realize that > LilyPond is in a very uncomfortable position w.r.t. Guile. I'll try > to find some time in the next few months to help more with the porting > effort. Well, at least Guile 2.0.10 has been released recently with the fix to the curried definitions, so we can expect those to be available for builds from distributions sometime this fall. Redefinitions in LilyPond itself have proven infeasible since they clashed with the module system, leading to warnings about definitions stemming from different modules. For similar reasons, most hot-patches of Guile will not be feasible unless we hot-patch the module system as well. -- David Kastrup
