David Engster <deng@...> writes:
> Stephen Leake writes:
>> "Eric M. Ludlam" <eric@...> writes:
>>> On 04/03/2013 07:50 AM, Stephen Leake wrote:
>>>> There is now another option. For parsing Ada, I've written a generalized
>>>> LALR parser, using wisent as a starting point. It's still beta code; see
>>>> http://stephe-leake.org/emacs/ada-mode/emacs-ada-mode.html, the section
>>>> on Ada mode 5.0
> This looks very interesting. However, I cannot download
> org.opentoken.stephe-2013-03-27.tar.bz2 (it gives me a 404).
Sorry, that should be org.opentoken.stephe-4.0w-2013-03-27.tar.bz2
(note the 4.0w). page fixed now.
> Also, I don't understand how you generate the parser. From the Makefile
> it seems you're using Opentoken?
> What are you using your Wisent-derived parser generator for, then?
I'm not. The wisi generalized LALR parser (not the parser generator) is
a rewrite of the wisent LALR parser.
>> It might make sense to integrate wisi into cedet, or it might make
>> sense to make it a separate ELPA package (I plan to do that with Ada mode).
> I really like how you're dealing with the grammar conflicts. If it can
> even deal with reduce/reduce,
> I would at least try port the C++ grammar to that.
> I'd *really* like to get our C++ parsing faster.
It does slow down the parser, relative to plain LALR. The slowdown is
proportional to the number of conflicts, and the number of tokens it
takes to resolve each conflict. A truly ambiguous construct yeilds two
(or more) successful parses, which is an error in wisi (the parser
doesn't know which set of actions to apply).
It should still be much faster than LL, I think.
You can turn on wisi-debug, load build/run-wisi-test.el, open
test/wisi/*.input, and run the parser via run-test-here; that will show
the parse states, including spawning and terminating parsers for
Hmm. I'll have to provide the *-wy.el files if you want to do that
without running Opentoken first. I guess I should include those in the
> I had a good look at semantic-bovinate-stream and profiled it with
> various tests (which is difficult because it's recursive), but I
> cannot see any possibility for major speedups, except going parallel
> (by using several Emacs processes) or rewriting it as a primitive in C
> (which the Emacs maintainers probably wouldn't like).
I don't think the Emacs maintainers object to using C for proven speed
gain, as long as it's significant.
Of course, I'd rather write it in Ada, and they probably would object to
>> That should be doable now; my intent is to make wisi useful for any
>> language. Although I have no idea how to cope with preprocessors such as
>> C and C++; they change the language that needs to be parsed, on the fly!
> This is dealt with on the lexing level, which "mostly works". It's still
> a major pain, though. A better solution would be to have a C
> preprocessor implemented in Emacs Lisp, which runs before the
Yes, that does seem the most robust approach. There is a small
preprocessor for Ada (not in the language standard), and I have to do
something with that.
>This does not sound terribly hard (the C preprocessor is pretty
> dumb, after all), but the main problem is that Semantic would see a
> different code than the user in his buffer, and you have to manage a
> mapping between the two.
Yes. C macros can insert whole lines; there is a C directive that says
what the original file and line is for #include, but I'm not sure that
works for other macros.
The Ada preprocessor preserves line numbers, and only substitutes text,
so that should be easier to manage.