[antlr-interest] Type Checking/Semantic Analysis

[houman babai]

Hello Everyone,

 

I am developing a simple typed language.  So far things have been going very well. Thanks to ANTLR and existing grammar samples, I have been able to create an AST without too much trouble.  

 

However, now I find that my grammar allows for statements such as TRUE > FALSE.  I would like to catch issues like this through semantic/type checking routines.

 

------>QUESTION 1: Is this a correct approach?  I mean should I catch these types of errors through semantic analysis or should I be relying on the parser to catch them?

 

My grammar also allows for variables so I really doubt that I can rely on the parser for all type checking.  So I decided to use ‘my own’ AST nodes and attempt type checking either recursively or using the VISITOR design pattern.

 

However, I haven’t seen any examples out there that approach the problem in this manner.  So


 

------>QUESTION 2: Is there a better way to do type checking or semantic analysis in ANTLR?  Are there any examples out there?  (or am I on the right track :-)?

 

Best Regards,

Houman


Martin Olsson <mnemo at minimum.se> wrote:
Thanks Alexey. I've been tampering with this lexer error handling for 8h
now, but now finally it works for the "¤" char atleast!

Now, is it possible to generalize this rule into something that traps more
or less everything that the lexer doesn't understand? I mean if someone
enters some other obscure char like £ into the source I want that
highlighted as a syntax error too (still without the lexer/parser stopping
its operation). I could of course add another rule just like the one
below, but there is too many chars that is not used in my language so I
would rather have a general rule if possible.

I also have another question on the same theme. My language does
assignments using the ::= operator and comparisions using the == operator.
Lot's of users will try to assign variables using the = operator instead.
Currently when someone tries to use "x=blah" my lexer believes that the =
is a partial == and thus it says "found 'b' but expected '='". This is all
very well, but at this stage the lexer also aborts its operations. All the
stuff below the faulty assignment does not get parsed. In this case I
would like something similar to what you taught me above, ie I dont want
the lexer to stop; I just want it to mark the = as a "bad token syntax
error" and then keep on going. Is this doable too maybe?


regards,
martin

> You can define lexer rule that accepts any wrong chars.
> The action for this rule should report error and skip
> wrong token. It is very similar to comment handling
> except for error reporting.
>
> in lexer:
>
> protected ERROR: "¤"
> {
> // report error
> $setType(Token.SKIP);
> }
>
> So, in case of "func¤tion" parser will receive
> two ID tokens: "func" and "tion".
>
> Regards,
> Alexey
>
> -----
> Alexey Demakov
> TreeDL: Tree Description Language: http://treedl.sourceforge.net
> RedVerst Group: http://www.unitesk.com
>
>
>
>
> ----- Original Message -----
> From: "Martin Olsson" 
> To: 
> Sent: Monday, August 01, 2005 1:33 PM
> Subject: [antlr-interest] Exception on obscure char but then continue
> lexing?
>
>
>> Hi,
>>
>> I'm using an ANTLR parser to detect syntax errors in a c-like language.
>> Currently if the lexer runs into for instance the char "¤" (which is not
>> a
>> part of my language) it will throw a NoViableAltForCharException which
>> is
>> then wrapped into a TokenStreamRecognitionException. I catch this and
>> display the syntax error in my editor.
>>
>> The problem is that ANTLR seems to stop parsing too at this time.
>> Instead
>> I would like it to throw an exception as above, but then just ignore
>> that
>> character and resume lexing more or less as if the erroneous char never
>> appeared (it should also, if possible, start over with flushed buffer so
>> that the chars "func¤tion" will not be interpretted as a valid
>> "function"
>> token.
>>
>> Is this possible with ANTLR 2.7.5 ? Are there any examples of this?
>>
>>
>>
>> Sincerly,
>> Martin
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20050801/2ef063b4/attachment.html