Re: gnat: time-slicing

[Robert A Duff <bobduff@shell01.TheWorld.com>]

dewar@gnat.com (Robert Dewar) writes:

> I actually like the use of the term erroneous as opposed to undefined,
> but
> in any case, the point is that both the terms undefined in C and
> erroneous
> in Ada are technical terms. In both cases you will get into trouble if
> you
> think of them as meaning just what they mean in English.

Quite true.

However, I think it's a Good Thing to choose technical terms that don't
confuse people, in so far as that is possible.  I don't agree with
Humpty Dumpty. ;-)

There are two points that Ada's "erroneous" is trying to get across:

    - Don't do it; it's evil.
    
    - The program might do anything whatsoever.

Ada's "erroneous" captures the first.  C's "undefined behavior" captures
the second.  Can you think of an English phrase that captures both?

How about "undetected error"?  The "error" part of it captures the
first.  And the "undetected" heavily implies the second.

(Too many C programmers think "undefined behavior" means "experiment
with the current version of your current compiler, and see what it does;
depend on that".)

> If you read a language standard, you must be prepared to acquire the
> technical
> terms that are used and understand them precisely. If you find that
> too much
> of a burden, then language standards are not for you. Now of course a
> text book
> or a tutorial is free to use any language it pleases.

Therein lies danger.  If the textbook uses different terminology, then
people will be confused when they see the RM terminology.  Better to
choose the RM terminology so that it doesn't go "too wrong" when
interpreted loosely.

If programmer 1 walks up to programmer 2, and asks "Is this here thing
erroneous?", it would be Good if they understood each other without
explicitly defining their terms.

>... There is
> certainly no
> reason why every programmer should need to know precise technical
> terms of
> the standard, and it is unrealistic to think they will.

I think it's a sign of trouble when the language definition needs to do
that.

> One of the rules we try to follow in GNAT error messages is NOT to
> rely on the
> precise meaning of technical terms.

In most cases, that's a good thing.

>... For example, everyone who reas the
> standard
> carefully knows that the term "package" does not include "generic
> package". There are many statements in the RM that depend crucially on
> this fact. But we
> try to avoid a GNAT error message that uses the word "package" in this
> formal
> sense, since informally a generic package is a kind of package in
> ordinary
> english.

That one doesn't bother me so much.  In English, "adjective noun" is not
always a subset of "noun", and people generally understand that.  For
example, a "questionable fact" is not a "fact", a "pseudo intellectual"
is not quite an "intellectual", an "incorrect proof" is not a "proof",
an "illegal Ada program" is not an "Ada program".  Etc.

Surely everyone can see that a "generic elephant" is not a particular
elephant, but is a prototype of elaphantness (elaphanthood?).

> Similarly, what everyone calls a package specification, package spec
> for short,
> is in fact NOT a package specification at all in the RM, but rather a
> package
> declaration, and there are RM statements that depend on this
> distinction, but
> we try to avoid depending on this in error messages
> 
> (actually internally in the GNAT sources, and externally to some
> extent, we
> have defined package spec, which is a term that does not appear in the
> RM,
> to mean package declaration :-)

I like it, and I use term "spec" that way, but this clever obfuscation
wouldn't be necessary if the syntax rules were a little bit more
user-friendly.

- Bob