Re: Evolutionary User Strategy - A Compromise

[Erik Sandberg]

On Thursday 13 July 2006 12:04, Anthony Youngman wrote:
> Might be an idea to look at Antlr then ...
>
> I don't know how effective it would be, but part of the purpose behind
> the v3 rewrite is to increase the number of languages that Antlr can
> generate. If you can define the grammar in Antlr it could then chuck out
> a lexer/parser written in Scheme :-) Is the current lily parser
> hand-written? 

no, it's written in bison. The lexer invokes an external parser to parse 
Scheme expression when needed.

> And yes, preservation of white space is apparently fairly easy.
> Although, I'm half inclined to say that if you "convert-ly" a piece,
> then it will or can output stuff according to a "pretty print" standard.

question is whether it's possible to write a grammar that is useful both for 
convert-ly and paper production at once, or if it's a better idea to use a 
simplified grammar for convert-ly. E.g.: in { \foo c4 c2 } it's difficult to 
know whether c4 and/or c2 are parameters to the function foo, or if foo just 
is a variable -- it might be that foo has been defined in an \included file. 
For convert-ly purposes, it might be sensible to always treat \foo as a 
variable, because that makes life simpler.

> Take a look at Antlr - www.antlr.org. I'd go straight to v3, which is
> due for release this summer. What you would need to do is define the
> lily grammar using a BNF style notation (I think the technical term for
> the style of grammar is LA or LLA). Antlr itself is written in Java -
> run it over your grammar and it will spit out a lexer and parser for
> you. You could either use the current C++ templates which would create
> your lexer and parser in C++ for feeding the results to Scheme, or write
> a bunch of Scheme templates and output the lexer and parser directly in
> Scheme. I don't mean to teach grandma to suck eggs but it sounds (from
> the implication that the parser is mixed-language) that you're not using
> a compiler-compiler such as flex/Bison, PCCTS or Antlr.
>
> And of course, going down this route, things head towards the typical
> nix "toolkit" approach :-) Grammars to input lily ASTs in various
> versions, grammars to output "pretty printed" or converted .ly files in
> various versions, grammars to transform ASTs especially ones generated
> from eg abc, Sibelius, Personal Composer files :-) 

I think it's easier to import from other formats directly to .ly, or to a 
known format such as MusicXML.

-- 
Erik