Re: [GLISS] turn xxx.yyy into ("xxx" "yyy")

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Thu, Oct 4, 2012 at 10:28 AM, David Kastrup <address@hidden> wrote:
>> [..]
>> So if we want to avoid this kind of fallacy, there are a few ways out.
>> I decided to take a reasonably safe route by foregoing lookahead for '.'
>> unless explicitly told so.  How does a function tell LilyPond to look
>> for a string sequence like that in a function argument?  Of course,
>> using the predicate.  The function sees a STRING token with an
>> associated string value `val' and it checks whether the predicate would
>> be fine with accepting val.  If so, the string gets accepted and
>> LilyPond does not look further.
>
> Sounds reasonable to me (assuming i understood it correctly)
>
>> One rather sobering consequence is that any command accepting a grob
>> specification will _not_ be able to take a proper string generated in
>> Scheme using #... for it.  It will always require at least a _list_ of
>> strings.  This is consistent with 2.16 behavior of \override/\revert etc
>> where you had to at least use $... to get a string into this place (it
>> is not consistent with the current more lenient 2.17 behavior, but it is
>> not likely anybody noticed so far).
>
> I don't understand this part.  Small example please?

Assuming \override-like-function is defined with an argument of type
symbol-list?, you get

\override-like-function #"Slur" ... -> argument error
\override-like-function #"Voice" . #"Slur" -> syntax error
\override-like-function "Slur" ... -> #'(Slur)
\override-like-function "Voice" . "Slur" ... -> #'(Voice Slur)
\override-like-function Slur ... -> #'(Slur)
\override-like-function Voice.Slur ... -> #'(Voice Slur)
\override-like-function $"Slur" ... -> #'(Slur)
\override-like-function $"Voice" . $"Slur" ... -> #'(Voice Slur)

#xxx tells LilyPond "please use xxx unchanged without any
context-dependent magic".

Currently \override _itself_ will accept #"Slur" as one form of a
specification, but that behavior is not older than a few weeks, so it is
unlikely anybody depends on it, and it would probably make sense to stop
it from accepting things that a musicfunction-based simulation would
have no access to.

> Overall LquiteGTM.

Hey, I have not even _started_ with issue/review, so merging is still a
bit away.  I am just in the state where all regtests pass after a set of
back-and-forth commits and I decided to do everything almost, but not
quite, entirely unlike before.

So I have some heavy rebasing to do, and then rewrite, and then it makes
some sense talking again about this.  I was just putting forth some
preliminary views of what I am doing and why it is taking me a bit
longer than anticipated to hammer this into a form

-- 
David Kastrup