Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #101 > unrolled thread

YACCaty YACC - Parsing YACC with YACC

Started byben senior <okobloko@googlemail.com>
First post2011-04-18 08:21 +0200
Last post2011-04-25 19:15 -0400
Articles 2 — 2 participants

Back to article view | Back to comp.compilers


Contents

  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

#101 — YACCaty YACC - Parsing YACC with YACC

Fromben senior <okobloko@googlemail.com>
Date2011-04-18 08:21 +0200
SubjectYACCaty 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]


#104

FromChris F Clark <cfc@shell01.TheWorld.com>
Date2011-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