[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and c

From: Graham Percival
Subject: Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.
Date: Sun, 29 Jul 2012 21:29:57 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jul 29, 2012 at 10:15:10PM +0200, David Kastrup wrote:
> Forwarding this from the lilypond-auto list since this review concerns
> an important syntax change.  GLISS material, in a manner.  Consider it a
> proposal for word and command syntax across _all_ lexer modes.

What's a "lexer mode" ?  I haven't gotten around to taking
Coursea's compilers course.

> One consequence is that if you can use \commandname in some context, it can  
> be defined using
> commandname = ...
> without requiring quote marks since word syntax and command name syntax are  
> in direct correspondence.

I don't see this as a huge benefit.  What's wrong with
  commandname = { ... }

> Being able to access every definition equally  
> well in every lexer mode is also an advantage.  The word definition is  
> palindromic: iff a character sequence is a word, so is its reverse.

If this means what I think it means, then huh?  so I can do this
  music = { c'4 d e f }
  { \cisum }
and have it compile?  or maybe I don't understand what a "word" is
in this context?  presumably it's not 8 bytes.

> If -  or _ is both preceded as well as followed by an alphabetic
> character, it  integrates into a word.

That sounds nice, although my time with programming languages
kind-of discourages the notion of
instead of
.  However, if it's totally safe to write "violin-one" then that
would certainly be nice for normal musicians!  It also saves one

>  It turns out that this definition works with  
> both "make test" as well as "make doc" without requiring any change in the  
> LilyPond code base.

That's certainly promising.

> Discuss.  This is quite a consequential change regarding what word syntax  
> is valid and what not, but the previous state was rather arbitrary to the  
> degree of being wonky.

Could I have some examples?  I just don't get this "word"
business.  Is there any syntax which was previously
(theoretically) supported, which this patch breaks?

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]