Thomas Morley <thomasmorle...@googlemail.com> writes:
> 2012/10/8 David Kastrup <d...@gnu.org>:
>> Keith OHara <k-ohara5...@oco.net> writes:
>>
>>> Werner LEMBERG <wl <at> gnu.org> writes:
>>>
>>>> > I lean towards letting numbers in function arguments just evaluate
>>>> > to themselves, never mind units.
>>>
>>> Sensible.
>>>
>>>> +1. However, it should be documented, together with the work-around.
>
> Speaking as a user:
> I never used 3\cm (don't like it), but I know others did (in \paper ).
> So no objection from me, and there will be the workaround.
>
> Do you suspect other disadvantages/changes than already mentioned?
There are a few other things that are simply unused and which I consider
phasing out since they don't really fit all too well with LilyPond.
Assignments can do some numeric expressions involving +, -. *. / but
without parentheses. Strings can be concatenated using +. The
consequences for that kind of thing are again involving lookahead. Its
effects are less onerous typically than within function arguments.
Forming expressions in Scheme is straightforward enough that a separate
(and not really documented or used) LilyPond layer that can't really be
used inside of function arguments does not appear to make all that much
sense.
There has been some talk about delimiting arguments. One change with
interesting consequences might be making { ... } equivalent to ##{ ... },
giving { ... } only "sequential music" grouping meaning when more than
one music expression is inside. This would give a rather painless way
of grouping arguments of arbitrary type. ##{ ... } is not all that
painful either, but it appears more contrived, in contrast. It would,
however, be a way to use things like the above mentioned LilyPond
expressions in arguments _and_ use { } for grouping expressions, like
{ 4\cm + \line-width }. With regard to those expressions, I am still rather
split between ripping them out and documenting them. Allowing them only
delimited within braces as function arguments might be an interesting
compromise.
It would require actually writing \sequential { ... } if you really,
really need sequential music, like as the target of \pushToTag (as a
workaround, \tag could take a look at its target and turn it into
sequential music if it is unsuitable for \pushToTag, but that is a bit
of an invasive change).
So there are a few drawbacks. One advantage would be that #{ #} and { }
would have a perfectly straightforward equivalence.
What I am currently doing is making LilyPond strings ("whatever" or
what_ever-huh) in function arguments equivalent to symbols if the
predicate does not accept a string. That's sort of a corollary of
turning xxx.yyy into a list of symbols. Of course, the regtests told me
that this disagreed with my too-clever argument list declaration of
\accidentalStyle which used symbols to distinguish
\accidentalStyle #'Voice "teaching" from \accidentalStyle "teaching".
The obvious fix to that is changing the syntax to
\accidentalStyle Voice . "teaching"
here, or just Voice.teaching. Accidental styles are, due to the current
word syntax, fine without quotes even for piano-cautionary or similar.
Making strings autoconvert to symbols when required releaves the user
from having to learn too many fine distinctions of the Scheme
interfaces. Implementing this is comparatively straightforward. What
is much harder is to decide _what_ input forms should be considered
"canonical" then and taught to users (and tools).
Two related tracks I am working on is removing special classes of
XXX_IDENTIFIER in the parser, and special classes of XXX_FUNCTION. If
that work is completed, you can do a lot of things using scheme
functions that are not possible right now.
Much is rather hand-wavy right now and without a clear list of followup
consequences and dependencies. "powerful, predictable, logical" are the
directions I try moving in, while retaining as much backward
compatibility as can be fit into that model. Some strategies regarding
the language design only evolve while I work.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
