David Kastrup <d...@gnu.org> writes: >> David Kastrup <d...@gnu.org> writes: >> >>> 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. > > On the plus side, I get, say, > cue-clef-after-barline.ly:28:38: error: ignoring specific Scheme value > \revert Score.BarLine #'space-alist > #'cue-clef > > which clearly points out a programming error.
I have reworked master such that make test now runs through when anything but SCM_UNSPECIFIED, SCM_BOOL_T or SCM_BOOL_F would get flagged as an error. I am not sure I'd keep the booleans. If you take a look at the eight commits or so, you'll find that the majority deals with plain wrong (nested revert syntax!) or at least ugly code. Those would most likely have been flagged even when Lilypond would have been trying to interpret them syntactically (as this interpretation would not have worked). So it would appear that there is some payback for the code that is going to get broken. I'll likely check in define-void-function and \void soonish, once I have adapted the programming documentation. Having a separate define-void-function that is certain not to return anything seems to make good sense. Now here is one thing worth considering: currently the predicate scheme? is defined as (define-public (scheme? x) #t) I lean towards defining it instead as (define-public (scheme? x) (not (eq? x (begin)))) so that it will accept anything _except_ void expressions. Does that appear like a good idea? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
