Re: Error definition

Bethan Tovey-Walsh writes:

> I’m inclined to agree with Dave. I wouldn’t call it an error if the
> implementation were only a recogniser: it would make sense in that
> context for the outcomes “yes, this is a sentence” and “no, this is
> not a sentence” to be of (potentially) equal interest and value. But
> the point of the ixml parser is to provide vxml output, not to tell
> you whether your input string is a valid sentence or not. If it can’t
> provide that output, I’d call that an error.

Note how firmly your argument is grounded in the psychology of the user
in the imagined usage scenario.

When the input is not a sentence, saying that an error has arisen makes
sense if our goal is to obtain a parse tree for the input, or to prepare
input which is a sentence.  If our goal is different -- for example, we
are trying to find input strings which are *not* sentences, the
unqualified terms 'failure' and 'error' seem to mean something else.

Imagine, for example, that you are in the XQuery WG in the nth year of
their joint work, and the group has decided to add yet another new
construct to the language.  Your job, as the person who knows about
grammars, is to devise a grammar for a new kind of expression, and check
that the sample expressions you derive from it are OK, which means
verifying that they don't already mean something else.  So you need to
verify that the samples are not currently grammatical against the
grammar for XPath.  If the candidate expressions fail to parse, you have
succeeded; if they parse, you have made an error.

Or imagine that you are trying to write an ixml grammar which recognizes
all and only Pascal-style comments: strings which begin '(*' and end
'*)' and can have any sequence of characters between those two strings
as long as it does not contain the string '*)'.  Or for that matter,
imagine you are trying to write an ixml grammar which recognizes all and
only strings which which begin '<!--' and end '-->' and contain no
occurrences of '--'.  If your grammar accepts the wrong strings, you and
your grammar are in error.  It it rejects the wrong strings, again, you
have made an error.  (I note in passing that a collection of some of the
brightest technical people I've ever worked with failed to find a
grammar to match the set described, at least for a while. The XML spec
adds the requirement that the contents not end in '-', but I no longer
recall whether that was because it was only with that addition that we
managed to find a formulation, or because SGML had that constraint.

The point of my examples being that we do not know and cannot constrain
the larger purpose for which a user invokes an ixml processor, and words
like 'failure' and 'error' can easily become confusing.

One of the salient properties of declarative information is that it can
be used in many different ways.  As John McCarthy put it long ago, if we
are given declarative statement that when something heavy falls, it
makes a noise, we can use it to find a way to make noise, or to find
ways to avoid making any noise, or to discover what has just caused a
particular noise.

If we want to speak of situations in which the input string is not a
sentence as involving parsing errors, no one can stop us.  But I hope we
will be careful to define our terms clearly and use them consistently,
and I hope that we will avoid assuming or decreeing that everyone who
invokes an ixml processor must have an appropriate goal or be in a
particular frame of mind.

I notice that the signals used in some computing environments to
indicate particular states of affairs are called in some contexts "error
conditions" and in others merely "exceptions".  I believe that the
latter usage is motivated by the fact that the word "error" so often
carries with it the suggestion that someone has *committed* the error by
doing something wrong.

Cobuild, for example, says "An **error** is something you have done which
is considered to be incorrect or wrong, or which should not have been
done. ... If you do something **in error** or if it happens **in
error**, you do it or it happens because you have made a mistake,
especially in your judgement."

If someone can explain to me why it is incorrect or wrong to submit an
input string and an input grammar to an ixml processor if the input
string is not a sentence in the language described by the grammar, then
my concerns will turn out to be groundless.

Thanks!

Michael

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

Received on Friday, 4 February 2022 17:42:48 UTC