As I remember, since I’m the one who
wrote the quite J with John C doing almost all the real work, the problem I had with
ANTLR was just the amount of work necessary to deal with the limited lookahead,
i.e. the k in LL(k). In C and C++ there is a ton of rules that look ambiguous
when you are only looking one or two tokens ahead. A lot of work is required to
refactor the grammar to fit in this environment.
With ANTLR v3, it has “infinite”
lookahead, i.e. the * in LL(*). Which means ANTLR will look as far down the
token stream as it needs to resolve ambiguities. Much less refactoring is required.
Also, the CDT parsers are LL(*), just handcoded. We do infinite lookahead with
backtracking. ANTLR v3 might actually be faster since it uses a state machine
to quickly rip through the tokens to pick which way to go where as our parser
does a “hunt and peck” method with the backtracking.
We’ll see who things work out and I
have no plans on rewriting the C and C++ parsers unless some requirement comes
up that necessitates all the work. The C# work is more like a sandbox to try
out some of these ideas and learn from them in case we do need to apply them.
It’s also help validate that we have the right multi-language framework
in place.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail
Sent: Friday, June 16, 2006 7:11
AM
To: CDT
General developers list.
Subject: RE: [cdt-dev] FW:
[eclipse-dev] C# plugin for Eclipse
Hi Doug,
>ANTLR is LL(*) BTW, where I assume LLK
is, well, LL(k). ANTLR is much more
>powerful and makes grammar writing a
hell of a lot easier. It actually >meets
>the needs we had for our C++ grammar
which we ended up doing by hand >because
>none of the parser generators could do
LL(*). Good times ahead for us >parser
>writers :)!
As I remember we have already had an
experience of using the generated parsers and the first CDT parser AFAIK was
generated by the JavaCC which as I understand is capable of generating LL(k)
parsers.
As I understand, this approach failed
previously and we have discarded it once in the past. Here is the snippet of
the CDT Parser Proposal dated by 01/14/2003 residing in the core-home:
"For simple languages .., one would
generally use a parser generator, such as JavaCC or ANTLR, to generate the code that
implements this algorithm.
.. However, when the language is
complex and ambiguous as C++ is and when we need to do special handling for
things such as the CModel (which needs to be so fast that we can't afford to
follow inclusions, thus leaving many types undefined) it is easier to write these algorithms by hand and this is how
the CDT parser is written."
What is the reason then in switching back
to parser generation?
Are there any advantages of using ANTLR
over JavaCC?
Thanks,
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Doug Schaefer
Sent: Thursday, June 15, 2006 10:21 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] FW: [eclipse-dev] C# plugin for Eclipse
I'm writing a C# grammar from scratch using an
early adopter version of
ANTLR v3 which is BSD licensed. Once ANTLR v3
reaches completion, I'll bring
it through the Eclipse legal to hopefully
allow it to be included in Eclipse
projects. For now, you'll have to download it
separately and install it into
the appropriate projects (more on that later).
ANTLR is LL(*) BTW, where I assume LLK is,
well, LL(k). ANTLR is much more
powerful and makes grammar writing a hell of a
lot easier. It actually meets
the needs we had for our C++ grammar which we
ended up doing by hand because
none of the parser generators could do LL(*).
Good times ahead for us parser
writers :)!
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On
Behalf Of Chris Recoskie
Sent: Thursday, June 15, 2006 2:12 PM
To: kap4020@xxxxxxx; CDT
General developers list.
Subject: Re: [cdt-dev] FW: [eclipse-dev] C#
plugin for Eclipse
They generate their parser via LLK. The
resulting generated parser code is
under the LGPL license, as they use the
example C# grammar, which itself
was LGPL. The LGPL is not compatible
with the EPL currently.
I am not a lawyer but I think that makes the
idea of contributing it to
Eclipse dead in the water for now.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Karol
Pietrzak
<kap4020@xxxxxxx>
Sent
by:
To
cdt-dev-bounces@e
cdt-dev@xxxxxxxxxxx
clipse.org
cc
Subject
15/06/2006 02:01 Re:
[cdt-dev] FW: [eclipse-dev] C#
PM
plugin for Eclipse
Please respond
to
kap4020@xxxxxxx;
Please respond
to
"CDT
General
developers
list."
<cdt-dev@eclipse.
org>
On Tuesday 13 June 2006 08:34, Doug Schaefer wrote:
> Yes, I have a Google SOC student working
towards that and I?ve been
working
> on a C# parser (at least until the CDT
3.1 storm hit). I think it?s a
> natural fit.
> I?ll have to think about how I?d organize
this activity. There is a lot
of
> work to do to make this happen, including
editor support, DOM support,
> managed build, debug. I?m not sure how it
fits in our mandate, whatever
our
> mandate really is, so I?ve been thinking
of hosting it at our SourceForge
> project, cdt-contrib.
> Anyone else interested in working on
this?
I second Mike Milinkovich's point that if CDT
seems to be the best place
for
a C# Eclipse, then so be it!
However, I would just like to point out that
there is already a C# Eclipse
plugin in current development [1].
It's also quite far along, with the following
features (quoted from the
webpage):
- Syntax highlight.
- Smart indent.
- Outline page.
- Format action and syntax checking.
- Comment and uncomment actions.
Doug Schaefer: I'm looking at the proposal,
and I'm not quite understanding
whether Rebecca Chernoff will be working on a
Mono Eclipse plugin or the
IDE
Generator?
Thanks!
[1]
http://black-sun.sourceforge.net/csharp-editor/index.html
--
Karl Pietrzak
kap4020@xxxxxxx
(See attached file: attplmda.dat)
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev