Related articles |
---|
Regex -> DFA ->? Lex compiler johnston.p@worldnet.att.net (Paul Johnston) (2000-02-05) |
Re: Regex -> DFA ->? Lex compiler webid@asi.fr (Armel) (2000-02-10) |
Re: Regex -> DFA ->? Lex compiler jandk@easynet.co.uk (Jonathan Barker) (2000-02-10) |
Re: Regex -> DFA ->? Lex compiler torbenm@diku.dk (2000-02-10) |
From: | "Armel" <webid@asi.fr> |
Newsgroups: | comp.compilers |
Date: | 10 Feb 2000 01:09:13 -0500 |
Organization: | WebID |
References: | 00-02-012 |
Keywords: | lex, DFA |
> 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
comp.compilers page.
Search the
comp.compilers archives again.