Re: How do feel people about the following change in syntax?

[David Kastrup]

David Kastrup <address@hidden> writes:

>> David Kastrup <address@hidden> 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