Re: New read/eval Scheme syntax inconsistent in handling existing code

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Valentin Villenave <address@hidden> writes:
>>>
>>> myvar = { b'4 }
>>>
>>> $(display "this shouldn't be needed anyway")
>>> $(eval-string "(define-public myvar #{ a'2 #} )" )
>>>
>>> \new Staff \myvar
>>
>> You need #(display ...).  $ takes a look at the type of the enclosed
>> expression and creates a token of the appropriate type in the input
>> stream.  The type of the enclosed expression is *unspecified* so nothing
>> gets inserted into the input stream by the lexer and the parser is
>> completely unimpressed.  With #(display ..., the resulting token type is
>> a Scheme token.  The parser throws it away in this context, but it knows
>> that a Scheme token can't be between { b'4 } and \addlyrics (for
>> example).  So the rule it exercises for throwing the Scheme token away
>> makes sure that the next token is not needed as lookahead token for
>> finishing the previous token.
>>
>> You can't write #(display ... in any context, only where Scheme tokens
>> are allowed.  $(display ... in contrast is allowed anywhere since the
>> parser never gets to see anything.  Since the parser does not get to see
>> anything, it does not change parsing.
>
> Actually, it was a deliberate change that $*unspecified* does not create
> SCM_TOKEN.  I considered it strange that there are places where you can
> write $(+ 2 3) but not $(display 3).  Yes, I did not actually discuss
> this change separately I guess.  Part of the reason is that $ was not
> used in the manner of making the parser skip a beat previously, so I saw
> no point in making it do it now.

Or put differently: the principal difference of # and $ is that $
interprets the resulting expression and generates a token corresponding
to its type (or in this particular case, none at all).  The premature
evaluation is a _side-effect_ of this difference.

If would appear that you consider the side-effect more important than
the main effect, and have for that reason decided to be smarter than
convert-ly and replace # everywhere with $.  Yes, you'll get the
side-effect back in that manner, but you'll also get the different
principal meaning.

Yes, if you write code relying on temporary insanities of Lilypond's
implementation and on meddling with internals, my work on Lilypond will
be disruptive to your document base.

The alternative would be to freeze Lilypond.  Not just its syntax, but
the entire implementation.


Looks like we have lots of fun ahead.  Do me a favor and from time to
time add material to Lilypond's documentation that would have helped you
avoid this kind of lock-in hack programming.  Once you know how to avoid
it.

-- 
David Kastrup