Related articles |
---|
Convincing an LR parser to emit fragments? miles@minster.york.ac.uk (1992-05-26) |
substring parsing miles@minster.york.ac.uk (1992-05-29) |
Re: substring parsing Jan.Rekers@cwi.nl (1992-06-02) |
Newsgroups: | comp.compilers |
From: | miles@minster.york.ac.uk |
Keywords: | parse, LALR |
Organization: | Compilers Central |
References: | 92-05-139 |
Date: | Fri, 29 May 1992 15:36:37 GMT |
Thanks to all those people who replied to my request for help
regarding substring parsing. The relevant reference appears to be:
@inproceedings { Corm89,,
title = "An {LR} Substring Parser for Noncorrecting
Syntax Error Recovery",
booktitle = "Proceedings of the SIGPLAN '89 Conference
on Programming Language Design and Implementation",
author = "Gordon V. Cormack",
pages = "161--169",
year = 1989}
However, I suspect that this approach will not be of practical use given
the fact that the resulting LR parser is double the size of the original
(non) substring parser. The reason for this lack of enthusiasm is that
the grammar that I intend to use generates 3106 LALR states and is thus
already unwieldy: 6k states moves the approach into the world of fantasy
(or a fast, big machine that York doesn't seem to have). The grammar that
I use will also be in a state of flux, given the fact that I hope to
induce rules in order to deal with undergeneration problems, and hence the
machine compilation time may be a significant overhead, unless I use some
sort of incremental approach.
The chart parser seems to be calling ...
Miles
miles@minster.york.ac.uk "All is vanity".
[A message from Andy Schuerr <andy@rwthi3.informatik.rwth-aachen.de>
mentioned Gregor Snelting, "How to build LR parsers which accept incomplete
input," in SIGPLAN 25:4, April 1990, pp 51-58.]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.