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

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Graham Percival <address@hidden> writes:
>>
>>> What happens if somebody writes
>>>   { \with foo    c4     \with bar    d4 }
>>> ?
>>
>> Good catch.  I don't think we want anything but a syntax error here.
>> One approach would be not to ignore Scheme expressions in a sequence
>> unless they evaluate to "unspecified" or at least a limited set of
>> "ignorable" values.
>>
>> More compatible would be the approach that you can omit braces only when
>> a certain construct is syntactically expected somewhere: if it is to be
>> produced "foreignly", use # or { ... }.  Then
>>
>> { { \with foo } c4 { \with bar } d4 }
>>
>> would be a music sequence with two Scheme expressions inside getting
>> ignored, and { \with foo c4 \with bar d4 } would be a syntax error.
>
> On the other hand: why silently ignore a likely side-effect-free
> expression?  It is likely to be a programmer error.  So I lean towards
> ignoring only expressions with "unspecified" value (basically all
> Scheme assignments) for the first attempt.  If tests with real-world
> documents show this to be too disruptive, one can think about
> alternatives.

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.

-- 
David Kastrup