From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63360011f8addace X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-31 15:31:30 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!news.umass.edu!world!news From: Robert A Duff Subject: Re: gnat: time-slicing Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Wed, 31 Jul 2002 22:28:57 GMT References: <5ee5b646.0207200347.2c61f610@posting.google.com> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:27542 Date: 2002-07-31T22:28:57+00:00 List-Id: 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