|Extending REG-EXP to 2-Dimension. firstname.lastname@example.org (1994-11-21)|
|Re: Extending REG-EXP to 2-Dimension. email@example.com (1994-11-30)|
|Re: Extending REG-EXP to 2-Dimension. firstname.lastname@example.org (1994-12-01)|
|Re: Extending REG-EXP to 2-Dimension. email@example.com (1994-12-03)|
|Re: Extending REG-EXP to 2-Dimension. firstname.lastname@example.org (1994-12-05)|
|Re: Extending REG-EXP to 2-Dimension. email@example.com (1994-12-05)|
|Re: Extending REG-EXP to 2-Dimension. firstname.lastname@example.org (1994-12-05)|
|Re: Extending REG-EXP to 2-Dimension. email@example.com (1994-12-08)|
|Date:||Mon, 5 Dec 1994 09:43:19 GMT|
Although I've often wished for this facility, I've never actually bothered
to think about what it involves before, so if I sound naive, that's my
It seems to me that the first problem is "what would a user expect this
to do?" The suggested "circles of text" seems fairly useless from a user's
perspective. I'd expect a user to be looking for something like one of:
- a single regexp that matches in one or more lines, i.e. there is one
match of the regexp for each line.
- a sequence of regexps, that can be matched to lines. The nth regexp
matches the nth line.
- a single regexp that matches the block of text, if that block of text
is first transformed into a "single" line (whether you treat newlines
a significant is optional here, I guess).
You can then further refine the semantics - in the first option, should
should all matches be the same as the first, or should any match do?
Once you've got a definition that the user could work with, *then* it
seems like a good idea to worry about the implementation.
Return to the
Search the comp.compilers archives again.