Re: Backtracking parsers

gneuner@dyn.com (George Neuner)
20 Jun 2000 02:28:10 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Backtracking parsers adrian@dcs.rhbnc.ac.uk (2000-06-01)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-01)
Re: Backtracking parsers gneuner@dyn.com (2000-06-06)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-09)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-10)
Re: Backtracking parsers cfc@world.std.com (Chris F Clark) (2000-06-14)
Re: Backtracking parsers gneuner@dyn.com (2000-06-20)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-20)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-20)
Re: Backtracking parsers michael.finney@acm.org (Michael Lee Finney) (2000-06-30)
| List of all articles for this month |

From: gneuner@dyn.com (George Neuner)
Newsgroups: comp.compilers
Date: 20 Jun 2000 02:28:10 -0400
Organization: Dynamic ReSolutions, Inc.
References: 00-05-111 00-05-119 00-06-015 00-06-032 00-06-037
Keywords: parse

On 10 Jun 2000 15:10:19 -0400, Michael Lee Finney
<michael.finney@acm.org> wrote:


>
>The reason that the difference is one of context free vs. context sensitive
>is that p3 will normally only match up to the first *. But, if the
>surrounding context forced a backtrack into p3 then the second * would be
>matched. So treating backtracking in this manner is a difference of
>context free and context sensitive patterns where "closed" patterns are
>context free and "open" (inline) patterns are context sensitive.
>
>Thus, by providing both pattern expressions and pattern macros, one can get
>either behaviour. This is important because sometimes long patterns are
>broken into pieces for readability and organization. But, clearly,
>breaking a pattern is not free from side effects. Thus allowing inline
>patterns means that breaking larger patterns into two or more smaller
>patterns can be done without changing the meaning of the original pattern.
>This is not possible in conventional BNF (or E-BNF), or indeed, in most
>other systems used to build complex grammars.
>


A couple of thoughts:


If the symbols in the pattern have no meaning individually, then the
language is no more than a regular expression.


If, OTOH, constituent clauses of the sentence [may] have individual
meaning, but the meaning of the composition changes when they are
individually recognized, then you've kicked the whole system up into a
realm where symbols are [for lack of term] "imagery", a "clause" is an
"idea", and "sentence" is a composition of ideas.


At this point, a "sentence" looks a lot like a paragraph in a human
language. However, in a human language, a paragraph typically
represents a set of related ideas, whereas in a computer oriented
language, a sentence typically expresses a single idea.




Recognizing that this was an academic question to begin with, what
would be the utility of machine recognition of such a language?
Humans can't agree on what human languages mean ... would you expect
the machine experience with such a language to be different?




George Neuner
Dynamic Resolutions, Inc.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.