Re: Error definition

Tom Hillman writes:

> I think *and* vice versa (at least under the hood), although that may
> be my own lack of knowledge and imagination!  I await confirmation
> from better minds than my own.

In practice, they can differ.

To take a close-to-home example:  in Earley's algorithm, the parser
constructs a large and complex data structure, often later called a
chart.  The input is a sentence in the language defined by the grammar
if and only if, when the chart is complete, a particular entry is
present.

Constructing a parse tree to demonstrate the derivation of the input is
a separate task.  (In Aparecium, the chart is implemented as a map of
maps, and on some inputs the construction of the chart and the
extraction of the parse tree take about equal time, though I think that
result is achieved only because of the careful pessimization of my
tree construction routines.)

> In any case, I don’t think it particularly effects the facts of the
> matter: if the output you expect is a vxml node, and your parser can’t
> produce one, I agree you should be given an error.

It all depends on how "error" is defined.  For reasons explained
elsewhere, in particular the fact that in a spec "error" often formally
denotes an instance of non-conformance, and in ordinary language often
informally entails that someone has done something against the rules, I
am nervous about using "error" without qualification to describe a
situation in which the input grammar and the processor are both
conformant and no one has done anything wrong.

The strong intuition of the CG members that a failure of the input to
parse is best described as an "error" does I admit weigh somewhat on the
other side of the balance.

Michael

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Friday, 4 February 2022 14:07:10 UTC