[antlr-interest] Réf. : Re: Known bug for antlr v3.2?

Jim Idle jimi at temporal-wave.com
Thu Dec 3 14:13:53 PST 2009


If you need to use local variables in predicates then better to use a scope than a global class member, which is prone to error in future maintenance.

 

However I think you are taking the wrong approach here. The problem with the gated predicate is that when a mistake is detected you will just throw a recognition exception and says something like “Syntax at error at line 5, offset 13 at ‘x’ “, which will tell the user nothing. Also, creating a token for each CHAR is going to be very inefficient as is checking a gated predicate for each of them.

 

You would be much better having an ID rule that takes some arbitrary number of characters and then when you are looking for an address, just check $ID.text length. If not 12 characters, then you can issue a good semantic error that says “Line 1, offset 0: Address fields must be exactly 12 characters and this one is 666”. You will then know exactly what is wrong with the input.

 

Jim

 

From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org] On Behalf Of loic.lefevre at bnpparibas.com
Sent: Thursday, December 03, 2009 2:06 PM
To: david-sarah at jacaranda.org
Cc: antlr-interest at antlr.org
Subject: [antlr-interest] Réf. : Re: Known bug for antlr v3.2?

 


Thanks for the reply but I work in fact on a grammar where the address *must* be exactly 12 chars :o( 

I'll try with a global parser attribute. 

Thanks, 
Loïc 





Internet   
david-sarah at jacaranda.org 

Envoyé par : antlr-interest-bounces at antlr.org 

03/12/2009 22:33 


Pour

antlr-interest at antlr.org 


cc

	

Objet

Re: [antlr-interest] Known bug for antlr v3.2?

 

		




loic.lefevre at bnpparibas.com wrote:
> Hello,
> while testing some gated semantic predicate:
> 
> address
> @init{int n=1;}:
>         ( {n<=12}?=> c=CHAR {n++;} )+
>         {
>             // check for address validity
>             final String t = $address.text;
>             if( t.length() != 12 ) {
>                 throw new InvalidSWIFTBlock1AddressException( t, 
> $c.getLine(), $c.getCharPositionInLine() );
>             }
>         }
>         ;
>         catch[MismatchedTokenException mte] { throw new 
> InvalidSWIFTBlock1AddressException( mte.token.getText(), mte.line, 
> mte.charPositionInLine ); }
> 
> 
> I encoutered problem after Java source generation:
[...]
> SWIFTMTParser.java:865: cannot find
>  symbol
> symbol  : variable n
> location: class 
> com.bnpparibas.acetp.foxhound.spec2009.parser.SWIFTMTParser.DFA1
>                         else if ( (LA1_23==12) && ((n<=12))) {s = 14;}

This happens when a predicate referring to a local variable is hoisted
into a DFA class. You can work around it by making 'n' a field of the
parser class (preferably with a more distinct name); then, the DFA1
instance will be able to refer to it because DFA1 is an inner class
of the parser.

Note that in general this might not work if there are recursive
invocations of the same rule, although that shouldn't be a problem
in this particular case (since <address> only refers to <CHAR>). There
are similar hazards if you reuse the field across rules.

Incidentally, for this example it *might* be simpler to eliminate n
and rely on the length check in the action -- this may consume
additional CHARs, but that's not necessarily a problem, given that
the producer of the input may have intended those CHARs to be part
of the address.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com


List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address

 
 
 
 
This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 
Do not print this message unless it is necessary,
consider the environment.
 
                ---------------------------------------------
 
Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire,
pensez a l'environnement.


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


More information about the antlr-interest mailing list