Related articles |
---|
[9 earlier articles] |
Re: coupling LALR with a scanner? paul@paulbmann.com (Paul B Mann) (2011-09-19) |
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-09-20) |
Re: coupling LALR with a scanner? cdodd@acm.org (Chris Dodd) (2011-09-23) |
Re: coupling LALR with a scanner? cfc@shell01.TheWorld.com (Chris F Clark) (2011-09-29) |
Re: coupling LALR with a scanner? armelasselin@hotmail.com (Armel) (2011-10-02) |
Re: coupling LALR with a scanner? cfc@shell01.TheWorld.com (Chris F Clark) (2011-10-03) |
Re: coupling LALR with a scanner? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-10-03) |
From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | Mon, 3 Oct 2011 21:08:39 +0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | 11-07-013 11-07-015 11-07-018 11-08-004 11-09-016 11-09-017 11-09-022 11-09-023 11-10-003 |
Keywords: | parse |
Posted-Date: | 05 Oct 2011 15:47:28 EDT |
Chris F Clark <cfc@shell01.theworld.com> wrote:
> I have come to this discussion a little late and may have missed some
> of the conversation, so excuse me if I say some things which are
> obvious and have been discussed before.
(snip)
> However, and here I think we come to the crux of the discussion, can a
> scannerless system disambiguate the potentially ambiguous use of / as
> a division operator and the start of a regular expression? I would
> argue that if the system is LR(k) for some finite k and the use of
> regular expressions is not restricted to some narrow (left, preceding)
> context (e.g. as in Perl where regular expressions are part of only
> specific operations like m/regex/ and ~=/regex/ (forgive me if my Perl
> is a bit rusty)), then the answer is no.
I could be completely missing the point, but it seems to me that you
don't have to restrict such RE to a narrow context as long as the
context isn't one where a division operator is allowed.
Division usually requires a preceding operand. In the contexts I would
expect a regular expression it would be either preceded by an operator
or be the beginning of an expression.
In writing AWK programs, where there are functions that take RE as
operands, I normally put then in quotes (") instead of slashes, as it
seems more obvious in the context. (A variable with the appropriate
value also works.)
-- glen
Return to the
comp.compilers page.
Search the
comp.compilers archives again.