| | |
- Method resolution order:
- FCLLexer
- antlr3.recognizers.Lexer
- antlr3.recognizers.BaseRecognizer
- antlr3.recognizers.TokenSource
- __builtin__.object
Methods defined here:
- __init__(self, input=None, state=None)
- mAND_(self)
- # $ANTLR start "AND_"
- mCOMMENT(self)
- # $ANTLR start "COMMENT"
- mDIGIT(self)
- # $ANTLR start "DIGIT"
- mIdentifier(self)
- # $ANTLR start "Identifier"
- mInteger_literal(self)
- # $ANTLR start "Integer_literal"
- mInteger_literal_wo_sign(self)
- # $ANTLR start "Integer_literal_wo_sign"
- mLETTER(self)
- # $ANTLR start "LETTER"
- mOR_(self)
- # $ANTLR start "OR_"
- mReal_literal(self)
- # $ANTLR start "Real_literal"
- mT__14(self)
- # $ANTLR start "T__14"
- mT__15(self)
- # $ANTLR start "T__15"
- mT__16(self)
- # $ANTLR start "T__16"
- mT__17(self)
- # $ANTLR start "T__17"
- mT__18(self)
- # $ANTLR start "T__18"
- mT__19(self)
- # $ANTLR start "T__19"
- mT__20(self)
- # $ANTLR start "T__20"
- mT__21(self)
- # $ANTLR start "T__21"
- mT__22(self)
- # $ANTLR start "T__22"
- mT__23(self)
- # $ANTLR start "T__23"
- mT__24(self)
- # $ANTLR start "T__24"
- mT__25(self)
- # $ANTLR start "T__25"
- mT__26(self)
- # $ANTLR start "T__26"
- mT__27(self)
- # $ANTLR start "T__27"
- mT__28(self)
- # $ANTLR start "T__28"
- mT__29(self)
- # $ANTLR start "T__29"
- mT__30(self)
- # $ANTLR start "T__30"
- mT__31(self)
- # $ANTLR start "T__31"
- mT__32(self)
- # $ANTLR start "T__32"
- mT__33(self)
- # $ANTLR start "T__33"
- mT__34(self)
- # $ANTLR start "T__34"
- mT__35(self)
- # $ANTLR start "T__35"
- mT__36(self)
- # $ANTLR start "T__36"
- mT__37(self)
- # $ANTLR start "T__37"
- mT__38(self)
- # $ANTLR start "T__38"
- mT__39(self)
- # $ANTLR start "T__39"
- mT__40(self)
- # $ANTLR start "T__40"
- mT__41(self)
- # $ANTLR start "T__41"
- mT__42(self)
- # $ANTLR start "T__42"
- mT__43(self)
- # $ANTLR start "T__43"
- mT__44(self)
- # $ANTLR start "T__44"
- mT__45(self)
- # $ANTLR start "T__45"
- mT__46(self)
- # $ANTLR start "T__46"
- mT__47(self)
- # $ANTLR start "T__47"
- mT__48(self)
- # $ANTLR start "T__48"
- mT__49(self)
- # $ANTLR start "T__49"
- mT__50(self)
- # $ANTLR start "T__50"
- mT__51(self)
- # $ANTLR start "T__51"
- mT__52(self)
- # $ANTLR start "T__52"
- mT__53(self)
- # $ANTLR start "T__53"
- mT__54(self)
- # $ANTLR start "T__54"
- mT__55(self)
- # $ANTLR start "T__55"
- mT__56(self)
- # $ANTLR start "T__56"
- mT__57(self)
- # $ANTLR start "T__57"
- mT__58(self)
- # $ANTLR start "T__58"
- mT__59(self)
- # $ANTLR start "T__59"
- mTokens(self)
- mWS(self)
- # $ANTLR start "WS"
Data and other attributes defined here:
- DFA8 = <class 'antlr3.dfa.DFA'>
- @brief A DFA implemented as a set of transition tables.
Any state that has a semantic predicate edge is special; those states
are generated with if-then-else structures in a specialStateTransition()
which is generated by cyclicDFA template.
- DFA8_accept = [-1, -1, -1, -1, -1, -1, 7, -1, -1, -1, -1, -1, 22, 23, -1, -1, -1, 29, 30, -1, ...]
- DFA8_eof = [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, ...]
- DFA8_eot = [-1, 24, 24, 24, 32, 24, -1, 24, 24, 24, 24, 43, -1, -1, 24, 24, 51, -1, -1, 24, ...]
- DFA8_max = [122, 85, 78, 84, 61, 85, -1, 65, 69, 82, 72, 42, -1, -1, 73, 83, 46, -1, -1, 82, ...]
- DFA8_min = [9, 85, 78, 84, 61, 65, -1, 65, 69, 80, 69, 42, -1, -1, 65, 67, 46, -1, -1, 82, ...]
- DFA8_special = [-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, ...]
- DFA8_transition = [[27, 27, -1, 27, 27, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, ...], [28], [29], [30], [31], [35, -1, -1, -1, 33, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, ...], [], [36], [37], [38, -1, 39], [40, -1, -1, 41], [42], [], [], [46, -1, -1, -1, 44, -1, -1, -1, 45], [47, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 49, -1, -1, -1, 48], [50], [], [], [52], ...]
- antlr_version = (3, 1, 2, 2147483647)
- antlr_version_str = '3.1.2'
- grammarFileName = '/work/projects/pyfuzzy/pyfuzzy/fuzzy/storage/fcl/FCL.g'
Methods inherited from antlr3.recognizers.Lexer:
- emit(self, token=None)
- The standard method called to automatically emit a token at the
outermost lexical rule. The token object should point into the
char buffer start..stop. If there is a text override in 'text',
use that to set the token's text. Override this method to emit
custom Token objects.
If you are building trees, then you should also override
Parser or TreeParser.getMissingSymbol().
- getCharErrorDisplay(self, c)
- getCharIndex(self)
- What is the index of the current character of lookahead?
- getCharPositionInLine(self)
- getErrorMessage(self, e, tokenNames)
- getLine(self)
- getSourceName(self)
- getText(self)
- Return the text matched so far for the current token or any
text override.
- match(self, s)
- matchAny(self)
- matchRange(self, a, b)
- nextToken(self)
- Return a token from this source; i.e., match a token on the char
stream.
- recover(self, re)
- Lexers can normally match any char in it's vocabulary after matching
a token, so do the easy thing and just kill a character and hope
it all works out. You can instead use the rule invocation stack
to do sophisticated error recovery if you are in a fragment rule.
- reportError(self, e)
- reset(self)
- setCharStream(self, input)
- Set the char stream and reset the lexer
- setText(self, text)
- Set the complete text of this token; it wipes any previous
changes to the text.
- skip(self)
- Instruct the lexer to skip creating a token for current lexer rule
and look for another token. nextToken() knows to keep looking when
a lexer rule finishes with token set to SKIP_TOKEN. Recall that
if token==null at end of any token rule, it creates one for you
and emits it.
- traceIn(self, ruleName, ruleIndex)
- traceOut(self, ruleName, ruleIndex)
Data descriptors inherited from antlr3.recognizers.Lexer:
- text
- Return the text matched so far for the current token or any
text override.
Methods inherited from antlr3.recognizers.BaseRecognizer:
- alreadyParsedRule(self, input, ruleIndex)
- Has this rule already parsed input at the current index in the
input stream? Return the stop token index or MEMO_RULE_UNKNOWN.
If we attempted but failed to parse properly before, return
MEMO_RULE_FAILED.
This method has a side-effect: if we have seen this input for
this rule and successfully parsed before, then seek ahead to
1 past the stop token matched for this rule last time.
- beginResync(self)
- A hook to listen in on the token consumption during error recovery.
The DebugParser subclasses this to fire events to the listenter.
- combineFollows(self, exact)
- computeContextSensitiveRuleFOLLOW(self)
- Compute the context-sensitive FOLLOW set for current rule.
This is set of token types that can follow a specific rule
reference given a specific call chain. You get the set of
viable tokens that can possibly come next (lookahead depth 1)
given the current call chain. Contrast this with the
definition of plain FOLLOW for rule r:
FOLLOW(r)={x | S=>*alpha r beta in G and x in FIRST(beta)}
where x in T* and alpha, beta in V*; T is set of terminals and
V is the set of terminals and nonterminals. In other words,
FOLLOW(r) is the set of all tokens that can possibly follow
references to r in *any* sentential form (context). At
runtime, however, we know precisely which context applies as
we have the call chain. We may compute the exact (rather
than covering superset) set of following tokens.
For example, consider grammar:
stat : ID '=' expr ';' // FOLLOW(stat)=={EOF}
| "return" expr '.'
;
expr : atom ('+' atom)* ; // FOLLOW(expr)=={';','.',')'}
atom : INT // FOLLOW(atom)=={'+',')',';','.'}
| '(' expr ')'
;
The FOLLOW sets are all inclusive whereas context-sensitive
FOLLOW sets are precisely what could follow a rule reference.
For input input "i=(3);", here is the derivation:
stat => ID '=' expr ';'
=> ID '=' atom ('+' atom)* ';'
=> ID '=' '(' expr ')' ('+' atom)* ';'
=> ID '=' '(' atom ')' ('+' atom)* ';'
=> ID '=' '(' INT ')' ('+' atom)* ';'
=> ID '=' '(' INT ')' ';'
At the "3" token, you'd have a call chain of
stat -> expr -> atom -> expr -> atom
What can follow that specific nested ref to atom? Exactly ')'
as you can see by looking at the derivation of this specific
input. Contrast this with the FOLLOW(atom)={'+',')',';','.'}.
You want the exact viable token set when recovering from a
token mismatch. Upon token mismatch, if LA(1) is member of
the viable next token set, then you know there is most likely
a missing token in the input stream. "Insert" one by just not
throwing an exception.
- computeErrorRecoverySet(self)
- Compute the error recovery set for the current rule. During
rule invocation, the parser pushes the set of tokens that can
follow that rule reference on the stack; this amounts to
computing FIRST of what follows the rule reference in the
enclosing rule. This local follow set only includes tokens
from within the rule; i.e., the FIRST computation done by
ANTLR stops at the end of a rule.
EXAMPLE
When you find a "no viable alt exception", the input is not
consistent with any of the alternatives for rule r. The best
thing to do is to consume tokens until you see something that
can legally follow a call to r *or* any rule that called r.
You don't want the exact set of viable next tokens because the
input might just be missing a token--you might consume the
rest of the input looking for one of the missing tokens.
Consider grammar:
a : '[' b ']'
| '(' b ')'
;
b : c '^' INT ;
c : ID
| INT
;
At each rule invocation, the set of tokens that could follow
that rule is pushed on a stack. Here are the various "local"
follow sets:
FOLLOW(b1_in_a) = FIRST(']') = ']'
FOLLOW(b2_in_a) = FIRST(')') = ')'
FOLLOW(c_in_b) = FIRST('^') = '^'
Upon erroneous input "[]", the call chain is
a -> b -> c
and, hence, the follow context stack is:
depth local follow set after call to rule
0 \<EOF> a (from main())
1 ']' b
3 '^' c
Notice that ')' is not included, because b would have to have
been called from a different context in rule a for ')' to be
included.
For error recovery, we cannot consider FOLLOW(c)
(context-sensitive or otherwise). We need the combined set of
all context-sensitive FOLLOW sets--the set of all tokens that
could follow any reference in the call chain. We need to
resync to one of those tokens. Note that FOLLOW(c)='^' and if
we resync'd to that token, we'd consume until EOF. We need to
sync to context-sensitive FOLLOWs for a, b, and c: {']','^'}.
In this case, for input "[]", LA(1) is in this set so we would
not consume anything and after printing an error rule c would
return normally. It would not find the required '^' though.
At this point, it gets a mismatched token error and throws an
exception (since LA(1) is not in the viable following token
set). The rule exception handler tries to recover, but finds
the same recovery set and doesn't consume anything. Rule b
exits normally returning to rule a. Now it finds the ']' (and
with the successful match exits errorRecovery mode).
So, you cna see that the parser walks up call chain looking
for the token that was a member of the recovery set.
Errors are not generated in errorRecovery mode.
ANTLR's error recovery mechanism is based upon original ideas:
"Algorithms + Data Structures = Programs" by Niklaus Wirth
and
"A note on error recovery in recursive descent parsers":
http://portal.acm.org/citation.cfm?id=947902.947905
Later, Josef Grosch had some good ideas:
"Efficient and Comfortable Error Recovery in Recursive Descent
Parsers":
ftp://www.cocolab.com/products/cocktail/doca4.ps/ell.ps.zip
Like Grosch I implemented local FOLLOW sets that are combined
at run-time upon error to avoid overhead during parsing.
- consumeUntil(self, input, tokenTypes)
- Consume tokens until one matches the given token or token set
tokenTypes can be a single token type or a set of token types
- displayRecognitionError(self, tokenNames, e)
- emitErrorMessage(self, msg)
- Override this method to change where error messages go
- endResync(self)
- A hook to listen in on the token consumption during error recovery.
The DebugParser subclasses this to fire events to the listenter.
- failed(self)
- Return whether or not a backtracking attempt failed.
- getBacktrackingLevel(self)
- getCurrentInputSymbol(self, input)
- Match needs to return the current input symbol, which gets put
into the label for the associated token ref; e.g., x=ID. Token
and tree parsers need to return different objects. Rather than test
for input stream type or change the IntStream interface, I use
a simple method to ask the recognizer to tell me what the current
input symbol is.
This is ignored for lexers.
- getErrorHeader(self, e)
- What is the error header, normally line/character position information?
- getGrammarFileName(self)
- For debugging and other purposes, might want the grammar name.
Have ANTLR generate an implementation for this method.
- getMissingSymbol(self, input, e, expectedTokenType, follow)
- Conjure up a missing token during error recovery.
The recognizer attempts to recover from single missing
symbols. But, actions might refer to that missing symbol.
For example, x=ID {f($x);}. The action clearly assumes
that there has been an identifier matched previously and that
$x points at that token. If that token is missing, but
the next token in the stream is what we want we assume that
this token is missing and we keep going. Because we
have to return some token to replace the missing token,
we have to conjure one up. This method gives the user control
over the tokens returned for missing tokens. Mostly,
you will want to create something special for identifier
tokens. For literals such as '{' and ',', the default
action in the parser or tree parser works. It simply creates
a CommonToken of the appropriate type. The text will be the token.
If you change what tokens must be created by the lexer,
override this method to create the appropriate tokens.
- getNumberOfSyntaxErrors(self)
- Get number of recognition errors (lexer, parser, tree parser). Each
recognizer tracks its own number. So parser and lexer each have
separate count. Does not count the spurious errors found between
an error and next valid token match
See also reportError()
- getRuleInvocationStack(self)
- Return List<String> of the rules in your parser instance
leading up to a call to this method. You could override if
you want more details such as the file/line info of where
in the parser java code a rule is invoked.
This is very useful for error messages and for context-sensitive
error recovery.
You must be careful, if you subclass a generated recognizers.
The default implementation will only search the module of self
for rules, but the subclass will not contain any rules.
You probably want to override this method to look like
def getRuleInvocationStack(self):
return _getRuleInvocationStack(<class>.__module__)
where <class> is the class of the generated recognizer, e.g.
the superclass of self.
- getRuleMemoization(self, ruleIndex, ruleStartIndex)
- Given a rule number and a start token index number, return
MEMO_RULE_UNKNOWN if the rule has not parsed input starting from
start index. If this rule has parsed input starting from the
start index before, then return where the rule stopped parsing.
It returns the index of the last token matched by the rule.
- getTokenErrorDisplay(self, t)
- How should a token be displayed in an error message? The default
is to display just the text, but during development you might
want to have a lot of information spit out. Override in that case
to use t.toString() (which, for CommonToken, dumps everything about
the token). This is better than forcing you to override a method in
your token objects because you don't have to go modify your lexer
so that it creates a new Java type.
- memoize(self, input, ruleIndex, ruleStartIndex, success)
- Record whether or not this rule parsed the input at this position
successfully.
- mismatchIsMissingToken(self, input, follow)
- mismatchIsUnwantedToken(self, input, ttype)
- recoverFromMismatchedSet(self, input, e, follow)
- Not currently used
- recoverFromMismatchedToken(self, input, ttype, follow)
- Attempt to recover from a single missing or extra token.
EXTRA TOKEN
LA(1) is not what we are looking for. If LA(2) has the right token,
however, then assume LA(1) is some extra spurious token. Delete it
and LA(2) as if we were doing a normal match(), which advances the
input.
MISSING TOKEN
If current token is consistent with what could come after
ttype then it is ok to 'insert' the missing token, else throw
exception For example, Input 'i=(3;' is clearly missing the
')'. When the parser returns from the nested call to expr, it
will have call chain:
stat -> expr -> atom
and it will be trying to match the ')' at this point in the
derivation:
=> ID '=' '(' INT ')' ('+' atom)* ';'
^
match() will see that ';' doesn't match ')' and report a
mismatched token error. To recover, it sees that LA(1)==';'
is in the set of tokens that can follow the ')' token
reference in rule atom. It can assume that you forgot the ')'.
- setBacktrackingLevel(self, n)
- setInput(self, input)
- # this one only exists to shut up pylint :(
- toStrings(self, tokens)
- A convenience method for use most often with template rewrites.
Convert a List<Token> to List<String>
Data descriptors inherited from antlr3.recognizers.BaseRecognizer:
- __dict__
- dictionary for instance variables (if defined)
- __weakref__
- list of weak references to the object (if defined)
Data and other attributes inherited from antlr3.recognizers.BaseRecognizer:
- DEFAULT_TOKEN_CHANNEL = 0
- HIDDEN = 99
- MEMO_RULE_FAILED = -2
- MEMO_RULE_UNKNOWN = -1
- tokenNames = None
Methods inherited from antlr3.recognizers.TokenSource:
- __iter__(self)
- The TokenSource is an interator.
The iteration will not include the final EOF token, see also the note
for the next() method.
- next(self)
- Return next token or raise StopIteration.
Note that this will raise StopIteration when hitting the EOF token,
so EOF will not be part of the iteration.
|