|Regex -> DFA ->? Lex compiler email@example.com (Paul Johnston) (2000-02-05)|
|Re: Regex -> DFA ->? Lex compiler firstname.lastname@example.org (Armel) (2000-02-10)|
|Re: Regex -> DFA ->? Lex compiler email@example.com (Jonathan Barker) (2000-02-10)|
|Re: Regex -> DFA ->? Lex compiler firstname.lastname@example.org (2000-02-10)|
|Date:||10 Feb 2000 01:09:13 -0500|
> The problem I have now is that I am failing to translate a *set* of
> regular expression into a lexical analyzer (rather than just one
> regular expression). If I had built this tool going from regex to NFA
> to DFA, rather than straight to a DFA, then this would be solved by
> constructing a new start state s0 and linking to each NFA pattern with
> an epsilon-transition, as shown on the diagram on page 130.
Don't mind this, in fact you don't have any problem, just imagine that
the success of a precise regular expression is on a special transition
(coded with a number which cannot represent a character). so :
- you consider joining ((YOUREGEXPR)#)|(OHTERREGEXPR)$)
where # and $ are your special codes
- construct your DFA as usually, considering that transitions bearing a
special code deal to success state (obviously the special code is associated
to the precise regexpr you want to recognize so when you have the special
transition, you know which regular expression it represents).
Return to the
Search the comp.compilers archives again.