Home » Archived » IMP » Importing existing YACC/Bison parser ti IMP
| |
Re: Importing existing YACC/Bison parser ti IMP [message #4744 is a reply to message #4538] |
Thu, 30 August 2007 15:31 |
Robert M. Fuhrer Messages: 294 Registered: July 2009 |
Senior Member |
|
|
Ali wrote:
> Bob,
>
> Thanks for uploading the documentation -- everything is clear and
> smoothly working now. As a first impression, it seems IMP can really
> generate an IDE with the least manual coding.
>
> I have an existing parser for an arbitrary language written in
> YACC/Bison. It basically is a .y file prepared for C. What is the best
> way of importing this file into IMP? Sorry if this is a pure LPG question.
LPG is also an LALR(k) parser generator, so the grammar rules themselves
should be able to be imported without problem. That is, the productions
(as distinct from the actions) should be acceptable to LPG as they are.
The action code has to be Java of course (obviously, Eclipse plugins must
be essentially pure Java), so without some tricky JNI-based code (which
is possible, though I don't personally recommend it), you won't be able
to reuse the C-based ASTs that the grammar was presumably written for.
You have two choices:
(1) let LPG generate ASTs for you from the grammar, or
(2) rewrite the C-based ASTs in Java
(1) is probably the more desirable approach, as it requires much less
(read: no) work to get the AST classes themselves.
Reusing C-implemented analysis code (name resolution, type checking,
etc.) that uses your existing AST classes is another matter altogether.
If it were Java, you could use it freely, but unfortunately, C-to-Java
translation services isn't something we can really help with. :-(
As for the lexer/scanner, LPG can also produce a scanner, though the
specification actually uses the same formalism (LALR(k)); the tokens
in this case are individual characters. This is actually quite powerful
(as compared to the usual regular expression-based specifications of
most lexical analyzer generators), as for example one can use context
when matching. The only down-side here is that LPG doesn't yet support
ENBF or character classes, so you have to write recursive rules where
you would ordinarily use closure operators like * and +, and you have
to explicitly enumerate character classes. This is something we're
hoping to address soon, but for now, it requires more manual work.
--
Cheers,
-- Bob
===================================================
Robert M. Fuhrer, rfuhrer@watson.ibm.com
Programming Technologies Department
IBM T. J. Watson Research Center
|
|
|
Re: Importing existing YACC/Bison parser ti IMP [message #529648 is a reply to message #4538] |
Mon, 26 April 2010 16:01 |
Anatoly Messages: 6 Registered: April 2010 |
Junior Member |
|
|
Hi Ali and Bob,
at the begging of this thread you were talking about documentation:
Quote: | Thanks for uploading the documentation -- everything is clear and smoothly working now
|
What kind of documentation are you speaking about?
I'm looking for a way to reuse ANTLR grammar or ANTLR-generated parser/lexer in IMP, so it seems to be helpful for me.
[Updated on: Mon, 26 April 2010 16:02] Report message to a moderator
|
|
| |
Re: Importing existing YACC/Bison parser ti IMP [message #566265 is a reply to message #4538] |
Thu, 30 August 2007 15:31 |
Robert M. Fuhrer Messages: 294 Registered: July 2009 |
Senior Member |
|
|
Ali wrote:
> Bob,
>
> Thanks for uploading the documentation -- everything is clear and
> smoothly working now. As a first impression, it seems IMP can really
> generate an IDE with the least manual coding.
>
> I have an existing parser for an arbitrary language written in
> YACC/Bison. It basically is a .y file prepared for C. What is the best
> way of importing this file into IMP? Sorry if this is a pure LPG question.
LPG is also an LALR(k) parser generator, so the grammar rules themselves
should be able to be imported without problem. That is, the productions
(as distinct from the actions) should be acceptable to LPG as they are.
The action code has to be Java of course (obviously, Eclipse plugins must
be essentially pure Java), so without some tricky JNI-based code (which
is possible, though I don't personally recommend it), you won't be able
to reuse the C-based ASTs that the grammar was presumably written for.
You have two choices:
(1) let LPG generate ASTs for you from the grammar, or
(2) rewrite the C-based ASTs in Java
(1) is probably the more desirable approach, as it requires much less
(read: no) work to get the AST classes themselves.
Reusing C-implemented analysis code (name resolution, type checking,
etc.) that uses your existing AST classes is another matter altogether.
If it were Java, you could use it freely, but unfortunately, C-to-Java
translation services isn't something we can really help with. :-(
As for the lexer/scanner, LPG can also produce a scanner, though the
specification actually uses the same formalism (LALR(k)); the tokens
in this case are individual characters. This is actually quite powerful
(as compared to the usual regular expression-based specifications of
most lexical analyzer generators), as for example one can use context
when matching. The only down-side here is that LPG doesn't yet support
ENBF or character classes, so you have to write recursive rules where
you would ordinarily use closure operators like * and +, and you have
to explicitly enumerate character classes. This is something we're
hoping to address soon, but for now, it requires more manual work.
--
Cheers,
-- Bob
===================================================
Robert M. Fuhrer, rfuhrer@watson.ibm.com
Programming Technologies Department
IBM T. J. Watson Research Center
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 00:14:21 GMT 2024
Powered by FUDForum. Page generated in 0.04175 seconds
|