|Crenshaw's Tutorial firstname.lastname@example.org (Colin Doncaster) (2000-01-19)|
|Re: Crenshaw's Tutorial email@example.com (2000-01-21)|
|Re: Crenshaw's Tutorial firstname.lastname@example.org (Jack Crenshaw) (2000-02-05)|
|Re: Crenshaw's Tutorial email@example.com (Joachim Durchholz) (2000-02-10)|
|Re: Crenshaw's Tutorial firstname.lastname@example.org (2000-02-12)|
|Re: Crenshaw's Tutorial email@example.com (Alan Fargusson) (2000-02-15)|
|Re: Crenshaw's Tutorial firstname.lastname@example.org (Randall Hyde) (2000-02-15)|
|Re: Crenshaw's Tutorial email@example.com (Joachim Durchholz) (2000-02-17)|
|Re: Crenshaw's Tutorial firstname.lastname@example.org (David Thompson) (2000-02-21)|
|Re: types, was Crenshaw's Tutorial Andrew.Walker@nottingham.ac.uk (Dr A. N. Walker) (2000-02-27)|
|Re: Crenshaw's Tutorial email@example.com (2000-03-23)|
|From:||firstname.lastname@example.org (George Neuner)|
|Date:||12 Feb 2000 22:44:28 -0500|
|Organization:||Dynamic ReSolutions, Inc.|
|References:||00-01-073 00-02-017 00-02-038|
Rearranged a bit for readability.
On 10 Feb 2000 01:16:03 -0500, "Joachim Durchholz"
>Jack Crenshaw <email@example.com> schrieb:
>> One big advantage of an LALR parse is that it can handle syntax
>> constructs that LL (recursive-descent) parsers cannot. That is true.
>> But these constructs rarely show up in practice, and there is at least
>> a reasonable argument that if you're designing a programming language,
>> you would be better off to choose one that _IS_ easily parsed.
C, C++, Java, ADA, SQL and Fortran are not LL(1) [Fortran is LL(k)
with a large k]. I agree with your comment about language design, but
it seems that the languages most people use don't adhere to it.
>Two remarks are in order here.
>1) I'm not aware of any consensus about which form of grammar is more
>"natural" or "easily parsed". For example, the LL paradigma is "give
>me the first symbol and I'll know what comes", while LR says "give me
>the left context and I know what comes".
LR actually says "give me the left context and the next symbol(s) and
I'll see if I can transition to a new left context". If a transition
isn't possible because of ambiguity, LR can buffer additional symbols
outside the context in anticipation (not prediction) of an eventual
successful transition to a new context.
LR explicitly looks at the context, any buffered symbols and the
lookahead symbol(s) when deciding what to do. In LL, the context is
implicit and decisions are based solely on the lookahead symbol(s).
>... Which of these is easier to read for a human is something that I'd
>really like to know.
>2) Non-LL languages may be rare (I don't really know) ...
Human languages are ambiguous and we tend to process language in an
LR-like way: we construct a context, look at the next symbol and try
to make a coherent adjustment to the context. If the new context
would be ambiguous, we accumulate and buffer new symbols until the
context plus the buffer is coherent [to the tolerance of the reader]
or until we decide that the sentence is gibberish and give up.
Because LR(k) is more powerful than LL(k) for any k, it follows that
humans should read a sentence in either form equally well.
BTW: it could also be argued that humans use predicated LL and
parallel alternative evaluation, but I don't think that is actually
true. Studies have shown that conscious thought tends to work
serially and short term memory can hold only a limited number of
symbols (about 10) at any one time. I do believe that we employ
parallelism in resolving the symbols to ideas - but not in
linguistically parsing the symbols.
Dynamic Resolutions, Inc.
Return to the
Search the comp.compilers archives again.