Re: Wrapping a GUI around flex-bison engine

[Hans Aberg]

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