RE: Evolutionary User Strategy - A Compromise

[Anthony Youngman]

I don't really understand grammars etc (which is why my DATABASIC thing
is on/off :-).

But from my experience with Antlr, I don't see why you should lose
stuff. Your PEG article mentions ASTs. I don't see that converting a .ly
file into an AST can be that hard. So, for example, we write a Antlr
grammar that creates a lexer/parser that turns the .ly into an AST. We
now write another grammar that converts the AST to a .ly file.

Provided we freeze the AST layout, it's dead easy to handle things like
the < > / << >> switch - the input grammar reads < and the output
grammar writes << etc.

The \addLyrics problem is a bit harder. I don't know whether we could
parse both old and new versions into the same AST, but if we couldn't, a
treeparser to convert between ASTs isn't that hard. Antlr does things
like converting between Java and C# ... !!!

Anyways, I would expect that we could share one AST between several
"incompatible .ly variants" of lily, and within that, an "either
direction" transform would be easy. It also means that adding import (or
export) of other formats would be easy - to import, write a parser
grammar to read the other format and a treeparser to transform the
resulting AST to the lily version. For export, go the other way. But it
modularises everything.

And you wouldn't lose things like \relative because you're using a pure
lexer/parser setup, that wouldn't even understand what \relative was :-)

I might play with this when I get my hands on Antlr 3, but don't bank on
it.

Cheers,
Wol

-----Original Message-----
From: Erik Sandberg [mailto:address@hidden 
Sent: 12 July 2006 13:55
To: address@hidden
Cc: Anthony Youngman
Subject: Re: Evolutionary User Strategy - A Compromise

On Wednesday 12 July 2006 12:59, Anthony Youngman wrote:
> Something I thought of (having seen the comment about convert-ly using
> grep ...)

It's not using grep, but it relies heavily on regexps (so it can
somewhat 
fairly be compared to sed).

> I've got an on-off thing about writing a DATABASIC compiler (never
mind)
> and have come across a tool called Antlr. It is a compiler-compiler
and
> generates lexers, parsers and treeparsers.
>
> IF someone wants to put the effort in, it may (or may not be) easy to
> define various grammars to read in and chuck out different music
> formats. It sounds as though a lot of the problems (like the swap
> between < > and << >> for example) would be easy. Especially given
> lilypond's structure it looks like it would be fairly easy to define
> grammars which can read in or chuck out different lily version
syntaxes,
> even the \addLyrics / \oldAddLyrics thing maybe.

I'd rather have a look at parsing expression grammars, see: 
http://en.wikipedia.org/wiki/Parsing_expression_grammar
Seems to combine simplicity of regexps with the power of CFGs. Doesn't
seem to 
be widely implemented though.

Another way could be to go via the syntax expressions I'm working on:
Instead 
of applying operations on .ly input, we could apply them to the parser's

output, and then use some built-in version specific mechanism to convert

finished files back to .ly. I thikn this would be both more reliable
than 
convert-ly, and possibly easier to maintain, but some text formatting
might 
be lost unless the syntax-expression->ly conversion is designed very 
carefully. Depending on how macros will be implemented, commands like 
\relative may be lost as well.

-- 
Erik


* ************************************************************************ *

This transmission is intended for the named recipient only. It may contain 
private and confidential information. If this has come to you in error you must 
not act on anything disclosed in it, nor must you copy it, modify it, 
disseminate it in any way, or show it to anyone. Please e-mail the sender to 
inform us of the transmission error or telephone ECA International immediately 
and delete the e-mail from your information system.

Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, 
Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 
2333.

* ************************************************************************ *