Re: Interactive parsing with Bison

[Satya]

> >> I do not understand what "dependencies" refers to in the context of
> >> Bison.  Are we talking about the same thing?
> >
> >     Oh, sorry, it should have been "file dependencies", i.e., how the
> >     file modification dates relate among files calling each other.
> > When
> >     using 'make', these file dependencies are written down
> > explicitly by
> >     giving the filesystem location of the files in the 'make' file,
> > and
> >     'make' then checks the file modification dates, and if a dependent
> >     file has been modified, the associated action (like a compile) is
> >     initiated.
> >
> > I know how Make works, but what I don't see is how it is relevant to
> > the issue at hand.  We're talking about a development interface for
> > Bison grammars.  Why are you bringing all this stuff which relates to
> > Make?
>
> Satya initially detailed how he thought the development work should
> proceed, so:

My apologies for any misunderstanding; I was discussing a development
idea to mirror the popular commercial IDEs available for parser
generation; These are limited to parser generation only and do not
integrate with the rest of what ever larger project you might be
working on;

The job of Bison is to generate code that will parse your input;
exactly how you integrate this code with your project is left as an
exercise to the project developer; it is of no concern for bison to
calculate file dependencies. And so it does not become a concern for a
Bison IDE.

> >     Now, the IDE's typically allows one to not having to write down
> > these
> >     file dependencies explicitly, but merely indicating the source
> > file.
> >     The IDE will then scan the source file for constructs such as
> >     '#include <filename>", identifying the file with file name
> >     'filename', adding it to the list of file dependencies of the
> > source
> >     file, and also doing this recursively in the included file.
> >
> > It seems like you are proposing an IDE for Makefiles.  That might be
> > useful, but shouldn't you discuss it with the Make maintainers,
> > instead of the Bison maintainers?
>
> And in this context, you are right: I think that if the proper
> development work is put at the appropriate place, the work for doing
> this GUI support of Bison will be relatively limited. On the other
> hand, if it is not done that way, doing the things that Satya has in
> mind for only Bison directly will involve too much work.

Well, I think I was talking about a very simple possibility. It might
be nothing like the work you have done on code warrior. That's because
code warrior is perhaps a general programming IDE and is perhaps an
interface to generating make files too.

My idea is really simple. Just have a front end where you can type in
your grammar (with syntax highlighting) and have it parse a test-input
string before you generate the final parser code; during this
simulated test-parse, you can set breakpoints in the input string and
observe the series of shifts and reductions on the stack and the
various state transitions. You can experiment with various sequences
of input tokens and play around with the grammar / language
specification before you finalize them;

The code for a parser can then be generated and you are free to do
whatever you want to do with it. Yes, it might be very restricted in
scope but nevertheless I believe such a tool can be of good use even
as a standalone package.

Satya.