David Kastrup <d...@gnu.org> writes:
> For a first test, I made Lilypond barf on everything non-unspecified. I
> did not get through with "make all" mostly because of several instances
> of module-define! which chooses to return a boolean. What a nuisance.
> I changed the error condition such that booleans were also considered
> acceptable. Apart from drumpitch-init.ly which chose to use map where
> for-each would have been appropriate, make all succeeded and make test
> is not failing all that much (unfortunately, the magic "grep" command
> for getting the bad source files does not work, and apparently the
> problematic files don't get deleted by make either when I call
> non_fatal_error so I get success on a second run without a make
> test-clean in between. I need some more sleuthing). All in all, looks
> promising with regard to not causing all too much breakage to existing
> code.
>
> After all, the Lilypond sources are more likely to contain weird
> embedded Scheme expressions called for side-effect but returning
> specific values than typical user code does.
>
> It might make sense to introduce a syntax change like that in two
> stages: in the first stage, one just complains about embedded Scheme
> that could be mistaken for something useful. Only in the second stage,
> one does not complain but interprets it accordingly.
Hm. The bad cases are mostly due to Scheme letting a function like
hashq-set! or set-object-property! return a value. How stupid.
A first measure had been the creation of
(define-macro (define-void-function . rest)
`(define-scheme-function ,@rest (begin)))
and using that instead of define-scheme-function in
music-functions-init.ly (up to now, Scheme functions are used there only
for effect rather than value).
There are still things like #(set-object-property! ...) in the source.
Redefining all those would likely be a bit overkill, so basically it
will be advisable to use something like
\ignore #(set-object-property! ...
or
\void #(set-object-property! ...
to silence the more obstinate Scheme expressions.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
