Štěpán Němec <step...@gmail.com> writes:
> On Wed, 19 Oct 2011 11:26:18 +0200
> David Kastrup wrote:
>
>> Ok. Now unfortunately, Guile has a number of functions that one would
>> expect to return SCM_UNSPECIFIED, but which return something else.
>> hashq-set!, set-object-property! and a few others. So I need a nice way
>> to tell Lilypond to ignore a Scheme expression even though it looks like
>> it could be used as a valid Lilypond construct. I considered
>> \call #(hashq-set! ...
>> but it is a bit misleading since the Scheme expression would be called
>> anyway. There is also
>> \ignore #(hashq-set! ...
>> but it sounds a bit like nothing would happen.
>> \do #(hashq-set! ...
>> looks nice, but due to namespace pollution, it is already taken by
>> Guile, quite like \eval.
>>
>> All in all, I can't think of anything better than \ignore. An
>> alternative syntax like ##(...) or ##[...] seems a bit too sneaky to
>> me. One other possibility would be \void. It might look a bit nicer:
>>
>> \void #(hashq-set! ...)
>> \void #(hashq-set! ...)
>>
>> rather than
>>
>> \ignore #(hashq-set! ...)
>> \ignore #(hashq-set! ...)
>>
>> It's a bit C-ish, but not all that bad, and it fits with
>> define-void-function.
>
> Yeah, \void seems the best of the listed alternatives to me (with the
> caveat that although reasonably familiar with Scheme, I'm as of now
> still quite unfamiliar with LilyPond's use of it), especially if you're
> going for `define-void-function' (and better than \ignore for the "like
> nothing would happen" reason in any case).
Lilypond uses Scheme for "music functions" and similar (much of the
stuff called with \something). There are some things which you can
enter as "Lilypond expressions" or as Scheme, and you can write Scheme
stuff to be interpreted as a Lilypond expression by wrapping it in
ly:export, like
#(ly:export #{ \markup { xxx } #})
So there is a difference between Scheme and Lilypond expressions which
one can explicitly cross for example using ly:export and #{ ... #} but
which is somewhat loose in some contexts.
The more power one moves to music functions, the more awkward
maintaining the distinctions gets. They are not all that easy to
explain to users as well.
So I am trying to obliterate the difference and basically make ly:export
redundant. This can cause problems with existing code that may rely on
Scheme expressions being evaluated but ignored in a number of contexts.
ly:export is also problematic since it needs to be detected and
evaluated in the lexer, _before_ the decision of what token is generated
is made. Since the token may actually be a lookahead token, this means
that something like
val = 2+3
#(do something with val)
will not work since Lilypond needs to first _evaluate_ #(...) before it
can even decide what kind of token it is and whether it might be part of
an environment.
Now this particular situation is a nightmare anyway, since, for example,
xx=#0.1
val = 2+3
\xx
#(begin)
#(display val)
is valid Lilypond code displaying 2.3. This syntactic quirk for
supporting units may have to change or get restricted to specific
contexts. It seems like a really bad idea. As a first measure, it
might only work when \xx is already a number even before getting
evaluated. In that case, one can make the syntactic decisions before
one has to _evaluate_ the expression (even though one has to read it
right away).
But it is not pretty anyhow.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
