--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "antlr-discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/antlr-discussion/sHqXIskCjBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to antlr-discussi...@googlegroups.com.
Hello
Thanks for the suggestion. My question is more general as i am coming across a lot of tokens which end up containing other tokens. Therefore, i could be doing something wrong conceptually as far as ANTLR is concerned and perhaps i need to convert some tokens to rules composed of irreducible and well defined tokens. Having said that, can i please ask:
1) Is a fragment still usable and visible on its own?
2) Are token references (tokens referenced inside other tokens) resolved properly? (i.e. MINUS:'-'; PLUS:'+'; SIGN:(MINUS|PLUS); NUM: SIGN? [0-9]+;
Hello againNAMESTR:[a-zA-Z][a-zA-Z0-9_]+;
I tried a number of different things, including specifying certain parts of the grammar as fragments but i still get the same error.
The test case is as follows:
alpha:NAMESTR;
The test string is "blah" and the error message is
"line 1:0 mismatched input 'blah' expecting NAMESTR"
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "antlr-discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/antlr-discussion/sHqXIskCjBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to antlr-discussi...@googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "antlr-discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/antlr-discussion/sHqXIskCjBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to antlr-discussi...@googlegroups.com.
Hello everyone
Thank you for your responses.
I think that my "problem" is a bit more complicated than that. Some dot delimited numeric lists denote versions and are supposed to have at least two elements ( i.e. 1.2), one of these versions is constrained to any series of 1.1 (or more). The other can be any digit delimited by dots up to any depth. A third rule (which i had to remove or rather re express) was parsing floating point numbers (1.1) and another one was parsing generic "values" including dot delimited numbers. A fourth rule was parsing identifiers, including accessing member attributes.
The majority of those i am re-expressing so that they make more sense.
But when it comes to Float VS "dot numeric" (of any depth but at least two) I am at loss. I don't know how to get ANTLR to recognise the difference.
In an earlier question of mine about expressing constraints like [0-9]{0,3} in ANTLR, another gentleman (whose name i can't find right now, sorry) had suggested that this kind of checking should occur as a semantic check.
I think that the use-case i describe above could support some (distant :) ) future modifications of ANTLR's meta-language to be able to express such token constraints. In this way the meta-language would be a stand-alone model of the language it describes containing all constraint information in one place, rather than half of it in the specification and half of it somewhere in the code.
In the meantime, any ideas on how to deal with that little problem are welcome :) (preferably not involving 'code'...i don't know which language could be used to build a parser in)
All the best
AA
To unsubscribe from this group and all its topics, send an email to antlr-discuss...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.