[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