Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #101 > unrolled thread
| Started by | ben senior <okobloko@googlemail.com> |
|---|---|
| First post | 2011-04-18 08:21 +0200 |
| Last post | 2011-04-25 19:15 -0400 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.compilers
YACCaty YACC - Parsing YACC with YACC ben senior <okobloko@googlemail.com> - 2011-04-18 08:21 +0200
Re: YACCaty YACC - Parsing YACC with YACC Chris F Clark <cfc@shell01.TheWorld.com> - 2011-04-25 19:15 -0400
| From | ben senior <okobloko@googlemail.com> |
|---|---|
| Date | 2011-04-18 08:21 +0200 |
| Subject | YACCaty YACC - Parsing YACC with YACC |
| Message-ID | <11-04-034@comp.compilers> |
Hi, Has anybody already written a LEX/YACC combo for parsing YACC grammars? Would it be better to try to parse the state table output.y you get by running yacc in debug mode? I'd like to create a tree for arbitrary YACC grammars (well, 'arbitrary' within reason). I'm aiming towards automatically generating a GUI 'Sentence Builder' from a grammar which offers users the ability to begin at the root "Start" token and choose how to progress according to which tokens the grammar would allow next. My secondary goal is to visualise the resulting sentences as a tree where any node can be relocated or reordered to a point where it would be allowed to fit. My wider goal is to use the original Grammer to generate Inversion of Control configuration files (e.g. Spring) for wiring up objects such that systems using differing technologies and platforms can be derived from the same Grammar.... however, the Grammar isn't actually much use unless there is a user friendly way to use it to generate concrete Grammar instances (sentences) which can be fed into the system (LEX/YACC) to then produce the wiring configurations. Perhaps that sounds totally over the top and ridiculous - but this "more reflexive" DSL approach seems a really nice way to give users a lot of controlled flexibility, whilst providing a way to abstract from implementation technologies. I'm just starting out down this road of using compiler-compilers... is this an appropriate usage? Am I wasting my time? Any and all advice deeply appreciated! Kindest Regards, Ben [The source code for Berkeley yacc and bison are available at the click of a mouse. If you want to do this, I'd make a mutant version of yacc. People have done sentence generators, mostly to create test data for compilers, although I can't think of anyone who let you reorganize the tree. -John]
[toc] | [next] | [standalone]
| From | Chris F Clark <cfc@shell01.TheWorld.com> |
|---|---|
| Date | 2011-04-25 19:15 -0400 |
| Message-ID | <11-04-037@comp.compilers> |
| In reply to | #101 |
There is a grammar for Yacc++ (which includes its lexer, which is in a yacc-like rather than lex-like notation) included with Yacc++. It is the same grammar we use to build the tool itself, stripped of the semantic actions. Being able to compile Yacc++ with itself was an explicit requirement we had from the beginning. ----------------------------------------------------------------------- Personal diatribe warning: Without a hack, one cannot write a plain yacc grammar in yacc, because the semicolon at the end of a rule is optional, one needs to look for identifier : to find the start of a new rule (end of the current one). this means that the grammar for yacc is LALR(2) and not LALR(1). Thus, there are yacc grammars in yacc, but they require this lexical trick to work. The notation for lex is also hard to parse, but mostly because of issues at the lexical level. This is because of the prevalent tendency of the Unix/C community of the time to like 1-character tokens with \ escapes. Most of the shell and make tools are similarly hard to deal with neatly lexically. The general regular expression syntax in Emacs or Perl is also likewise obfuscated, with slight variations that can make them subtly incompatible. However, it is worth noting that the issues with dealing with the lexical issues is balanced by the terseness of the notation and the fact that one can often read them with a C program that looks only at 1 character at a time. It is just a personal foible that I prefer a language that is highly consistent to one which is terse. The other tends to lead to ad hack processing fraught with special cases that are never fully generalized. ----------------------------------------------------------------------- Final note, if you want a copy of Yacc++ for personal [non-commercial] use, send me an email explaining what you want to do with it. I "give away" to individuals a free version with the limitation that any software built with it must be GPLed. Hope this helps, -Chris ****************************************************************************** Chris Clark email: christopher.f.clark@compiler-resources.com Compiler Resources, Inc. Web Site: http://world.std.com/~compres 23 Bailey Rd voice: (508) 435-5016 Berlin, MA 01503 USA twitter: @intel_chris
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compilers
csiph-web