[antlr-interest] Antlr v3.0ea8 : @header not takenintoaccountinautomatically generated lexer java code...

[Jim Idle]

________________________________

From: antlr-interest-bounces at antlr.org on behalf of Don Caton
Sent: Thu 5/4/2006 5:59 PM
To: 'ANTLR Interest'
Subject: RE: [antlr-interest] Antlr v3.0ea8 : @header not takenintoaccountinautomatically generated lexer java code...



Jim:

> I would wish to discourage the use of include files that
> carry code, in favor of solving any issues that people find
> this to be the only solution for, in a more elegant fashion.

> In general I agree, but the problem is mixed-language programming.

> I put any non-trivial code in a header file that's included in the lexer or
> parser's generated code.  This allows me to edit the C++ code in the normal
> code editor (I use Visual Studio) and retain all the benefits of syntax
> highlighting, Intellisense, and all the other stuff you get in a
> language-aware code editor.


Understood in an ANTLR2 context - however, at least for C actions, I intend to produce the Visual Studio 2005 plug-in that is able to deal with this. ANTLR3 makes it pretty easy to switch between embedded languages. 

However, the C generator is such that you will be able to deal with code that is not action code in a 'more elegant fashion' ;-). The grammar will produce a .h file that you can include in other C files and reference the parser/lexer elements. Hence you will get teh intellisense etc in the natural fashion, and compile and link the individual source files.

I deliberately constructed the header and typedefs and so on such that Visual Studio, and I presume other IDEs, are able to pick up all the intellisense information correctly (no macros with code that hides such information for instance), and when you wish to do things like install your own error handler, you do this by intializing the parser/lexer and then install ing a pointer to your own function that matches the declared function spec. There are no non-static globals and therefore you should find, in C, that there is no need to include other C functions in the generated translation unit. My intent is that as people come to use this, I will attempt to accomodate any particular/peculiar requirements in a similar fashion.

I hasten to add that this has not been written with Windows only in mind though. It will be available for UNIX and OpenVMS from the start. 

Later, I may look at adding other languages in to the VS2005 add-in, or perhaps the other codegen authors would be able to. Still a little way out from here though. I need to finish off the tree parser support next week and then hopefully the C codegen will be ready for Ter's next EA release.

Jim