[Top][All Lists]

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

Re: LilyPond strings and \markup

From: Trevor Daniels
Subject: Re: LilyPond strings and \markup
Date: Mon, 17 Aug 2009 10:07:59 +0100


I'm top-posting as I'm not answering any of your specific questions.

If you really want to understand how data types are defined you will need to understand how lexers and parsers work first. To help, I've just added a few more clues to the Technical glossary. Then you will find all the answers in the two files which define the lexical and syntactic structure of a valid LilyPond file, or maybe start with the grammar in App C, which is extracted from parser.yy. But it would be wrong to try to double-guess the syntactic structure, and also wrong to invent new names and definitions for data types which are not exactly based on the ones defined in the LilyPond grammar. Hence the defined grammar needs to be understood first.

Sorry if this is not helpful, but it's going to be a long haul if you try to extract all the details by asking random questions on the list, especially as few of us are any more familiar with the details of these files than you are, and would have to refer to them to extract the answers.


----- Original Message ----- From: "Mark Polesky" <address@hidden> To: "Carl Sorensen" <address@hidden>; "Joe Neeman" <address@hidden>
Cc: "lilypond-devel" <address@hidden>
Sent: Monday, August 17, 2009 8:59 AM
Subject: Re: LilyPond strings and \markup

Carl Sorensen wrote:
Because \[alphanum]+ is a STRING_IDENTIFIER.

Not always:

num = 1
sym = #'symbol

% error: syntax error, unexpected NUMBER_IDENTIFIER (\num)
% \num

% error: syntax error, unexpected SCM_IDENTIFIER (\sym)
% \markup \sym

Remember, these are *parser* error messages.  They come from
interpreting the symbols in the input stream, not from
evaluating the variables resulting from parsing the input

The error message happens when the parser sees the text, not
when the parser evaluates the text.

If that were true, then wouldn't the NUMBER_ and SCM_IDENTIFIERs
above all be STRING_IDENTIFIERs?

Carl, you're being a good sport trying to help me understand
all of this. But it's just very counterintuitive to me. And it
continues to be. I'm repeatedly told to look at parser.yy and
lexer.ll (or whatever they are). But most of that code is too
unfamiliar for me to understand.

At first I thought there was such a thing as a LilyPond STRING, as
if it were a datatype in the traditional sense. But then I find
out that LilyPond STRINGs have different rules when they're in
\markup, and glancing at the lexer/parser code, it looks like
there's yet another set of rules for lyrics.

I'm trying to find accurate definitions for these basic concepts,
as in my initial attempt:

A valid LilyPond unquoted 'STRING':
1) must be entirely alphabetic, and
2) cannot be interpreted as a number, pitch, rest, or operator.

But I wasn't able to determine this definition from anything I
could find in the lexer/parser files. It's more based on a
combination of experience and trial-and-error. It's frustrating
that barely any of us seem to know what a STRING really is in our
own programming language.

Perhaps it would be better to refer to three types of strings:
"markup string", "lyric string", and, I don't know, "common

And then there's the whole thing where # and \ seem to behave the
same way, but only some of the time. The fact that there's more
than one way to define something, and more than one way to refer
to something, inevitably leads to confusion.

And then # is by turns required, optional, and invalid...

% ex.1.   # required:
\markup { left \hspace #1 right }

% ex.2.   # optional:
one = #1

% ex.3.   # invalid
\markup #1

To mix things up even further, quotes are optional in ex.3 and
invalid in ex.1.

Come on, you have to admit that this is terribly confusing! And as
far as I can tell, none of this is satisfactorily documented. I'm
trying to do something about it, but my goodness, I've already hit
the wall on my first datatype.

I hope I'm not annoying anyone here, but I stubbornly want to
understand these things. And try as I might, I'm not getting it
yet. I really do appreciate everyone's help so far -- but it looks
like I need some more.

Thanks guys.
- Mark

lilypond-devel mailing list

reply via email to

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