[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wrapping a GUI around flex-bison engine
From: |
Hans Aberg |
Subject: |
Re: Wrapping a GUI around flex-bison engine |
Date: |
Sun, 14 Nov 2004 19:43:42 +0100 |
User-agent: |
Microsoft-Outlook-Express-Macintosh-Edition/5.0.6 |
On 2004/11/10 00:56, Andrej Prsa at address@hidden wrote:
> Sorry to be a bit off-topic here, but I was wondering if anyone can
> suggest a good (perhaps the usual?) way of wrapping a graphical user
> interface (GUI) around an interactive flex-bison engine?
Do you mean a GUI for Bison, or a GUI for a Bison generated parser? The rest
of your text suggests it is the latter, which I will assume in my answer
below.
> In particular: I created a small engine that takes commands either from
> external files (scripts) or interactively using readline library, creates
> an AST and executes it.
There were a couple of postings some time ago in this list about making a
Bison parser work with readline.
>Now that I'm happy with that, I'd like to offer
> users to click around rather than type around. I've searched the internet
> for a nice approach for this, but I can't say I found the definitive
> answer.
As for creating AST's, there is only the hands-on approach supported. You
might ask in the newsgroup comp.compilers for other programs.
>In a nutshell, the GUI is supposed to supply the engine with
> commands or sets of commands (in either AST form or in string-buffer
> form), which are then executed.
I am not sure what exactly you have in your mind here: The Bison parser
processes a token stream. It does not matter how this token stream is
generated. You can create it via GUI or a standard text stream, which is
tokenized using a lexer.
>Furthermore, I'd like to have a
> plugin-aware engine, so that new pieces of code may be added to expand the
> basic functionality - I suppose the GUI is thus just one of perhaps many
> plugins to the engine. So if you have any ideas or recommendations, I'd be
> very grateful to hear them!
If you somehow want to create a dynamically extensible grammar, forget about
Bison: at best, one can create dynamic grammar subparts parts, if the
subparts are written by hand or some other tool. Bison uses a parser
generating algorithm, LALR(1), which treats the grammar as one whole, and a
change in the input grammar requires a complete recomputation of the output
parser. In general, the more dynamic (extensible) a parser is, the harder it
becomes for the user. So therefore, one often settles for a fixed grammar,
where say one can add cutomized operators. Here are some references on
dynamic grammars (you may want to check out in the newsgroup comp.copmilers
for more):
DINO (simple language with Early parser)
http://cocom.sourceforge.net/dinoload.html
ACCENT <http://www.combo.org/accent/>, an Earley parser generator tool along
the lines of Yacc.
SPARK <http://csr.uvic.ca/~aycock/python>, the Scanning, Parsing, And
Rewriting Kit. Provides support for compilation of little, domain-specific
languages in Python, although it has been used for larger projects. Uses
Earley's algorithm for parsing.
Languages with dynamic grammars:
- Thirty years ago languages like IMP72 and EL/1 let you change the
syntax on the fly by including BNF-like stuff in the input.
- Meta-S:
http://members.shaw.ca/qjackson/
http://members.shaw.ca/qjackson/cs/glossary/adaptive_backus_naur.html
http://citeseer.nj.nec.com/jackson02some.html
http://members.shaw.ca/qjackson/cs/glossary/adaptive_k.html
- Code Worker is a scripting language http://codeworker.free.fr
- The JavaCC lexer generator builds a full FA during the process of
generating the lexer.
Hans Aberg