Russian Version of Ada Programming Language Standard
Mendlowitz
Standard (ANSI/Mil-STD 1815A)? Has the standard been translated into
any other language? I would appreciate any information.
Richard Riehle
>official. I know that the French and German translations have been
>adopted by the national standards bodies, and the ISO standard
>references both the French and American national standards. I also
>know of Danish, Swedish, Italian and Japanese translations, but I'm
>not sure which ones have been officially adopted. Any others?
>
>--
>
> Robert I. Eachus
>
>with Standard_Disclaimer;
>use Standard_Disclaimer;
>function Message (Text: in Clever_Ideas) return Better_Ideas is...
saf...@ocvaxa.cc.oberlin.edu
First of all, what are you referring as "russian version" of Ada????
Computer languages are not meant to be translated into any human languages...
Second of all, why in the world are you interested in this monster???
P.S. Should you be interested in obtaining Ada compiler, get in touch with
ACM => during the last conference full latest version of Ada was selling
for $10 (on a CD of course, where else would you manage to squeeze this
POS).
alex f
+--------------------------------+---------------------------------+
{ Alexander Fadeev : phone: (216)-775-1002 }
{ === : mail: OCMR #608 }
{ (o o) : Oberlin, OH, 44074 }
+-------ooO-(_)-Ooo--------------+---------------------------------+
"Men and nations behave wisely afa...@cs.oberlin.edu
when they have exhausted saf...@ocvaxa.cc.oberlin.edu
all other alternatives." bfa...@ocvaxc.cc.oberlin.edu
David Weller
<saf...@ocvaxa.cc.oberlin.edu> wrote:
>In article <1994Apr4.1...@aio.jsc.nasa.gov>, Mendl...@asd2.jsc.nasa.gov (Mendlowitz) writes:
>>Does anyone know of a Russian version of the Ada Programming Language
>>Standard (ANSI/Mil-STD 1815A)? Has the standard been translated into
>>any other language? I would appreciate any information.
>
> First of all, what are you referring as "russian version" of Ada????
Russian version of the Ada RM. RTF-Message.
>Computer languages are not meant to be translated into any human languages...
> Second of all, why in the world are you interested in this monster???
>
Ahem. I've been told it's bad form to display stubborn ignorance on
the net. I guess the word hasn't reached your neck of the woods.
>P.S. Should you be interested in obtaining Ada compiler, get in touch with
>ACM => during the last conference full latest version of Ada was selling
>for $10 (on a CD of course, where else would you manage to squeeze this
>POS).
It fits on two floppies, which, after storing your total knowledge of
Ada, would leave and additional 2.87Mb for the compiler. Plenty of
space. Get a clue. Read the sig below and come back when you're
smarter.
>"Men and nations behave wisely afa...@cs.oberlin.edu
>when they have exhausted saf...@ocvaxa.cc.oberlin.edu
>all other alternatives." bfa...@ocvaxc.cc.oberlin.edu
You apparently have a few alternatives left :-)
--
Ada 9X: Try it again for the first time! Free Ada 9X compilers can be found
at cs.nyu.edu under /pub/gnat. Free reusable components from wuarchive.
wustl.edu under /languages/ada. Free reference manual and help guides can be
found at ajpo.sei.cmu.edu under /public/ada9x. || Subliminal Suggestion:
The Ada WWW Server is http://lglwww.epfl.ch/Ada/ || OS/2 :-)
Robert I. Eachus
I think there is a Russian translation, but I don't think it is
saf...@ocvaxa.cc.oberlin.edu
>In article <2nplcn$h...@news.cc.oberlin.edu>,
>
>>P.S. Should you be interested in obtaining Ada compiler, get in touch with
>>ACM => during the last conference full latest version of Ada was selling
>>for $10 (on a CD of course, where else would you manage to squeeze this
>>POS).
>
>It fits on two floppies, which, after storing your total knowledge of
>Ada, would leave and additional 2.87Mb for the compiler.
BTW, why such a bizarre choice??????????
>Plenty of space. Get a clue. Read the sig below and come back when you're
>smarter.
Ada for mac: Price: $10 + tax (CD)
Volume (uncompressed): ~4x Megs
Classification: a)."Neydachnoe screschenie
slona s nosorogom";
b)."Ne vinovatay ya, on sam
prishol";
Dmitrii Manin
In article <2ntarl...@umbc7.umbc.edu> ma...@umbc.edu (Marik Meytin) writes:
" <saf...@ocvaxa.cc.oberlin.edu> wrote:
" >Mendl...@asd2.jsc.nasa.gov (Mendlowitz) writes:
" >
" > First of all, what are you referring as "russian version" of Ada????
" >Computer languages are not meant to be translated into any human languages...
"
" I remember my roommate over in Moscow, whose favorite was BASIC translated
" into uzbek... (The arguments that BASIC is not a language, although somewhat
" valid, will not be accepted... ;)
And recall Algol-68, which had an official Russian version. There were
some cute equivalents for English-language terms. I don't remember
much, but I like to say, for example, "privedenie/privodit'" instead
of horrendous "kastnut'" ("cast").
Algol-68, btw, is the best by far of procedural languages. It's
unsurpassed up to now. Every time I try to entertain myself by
studying C++, I involuntarily compare and turn away disgusted.
--
- M
------------------
|OFORMLENIE VITRINY|
------------------
Alexy V. Khrabrov
> Not sure about the standard itself, but the most popular reference
> has been "Ada: An Advanced Introduction" by Gehani, published in
> 1988 by "Mir" under the title "Yazyk Ada" ("Ada Language")
This book is convoluted, binding a fair translation of the N. Gehani's
book with the (fair) semi-official Russian translation of the English
language text in the ANSI/MIL-STD-1815A-1983. This was the only action
of Russian ada enthusiasts, supported by the government. The intent was
to make it a GOST (~USSR's ANSI; now ghost...) standard, and then to
adopt a CEA's one. (CEA, the former Eastern European, Soviet and its
satellites, Council for mutual Economic Aid.) The full history of the
Russian Ada on the sunset of the Empire is known, for instance, to Dr.
Rybin at Moscow University:
I received an Overview "Ada in Russia," which was sent by him to the
Ada Letters. Summarizing, Ada in Russia deteriorates as any other
propriate high-tech in the former USSR now. If anybody has ideas about
Russian Ada Rebirthing and Expansion (RARE), please sent'em to Dr.
Rybin, and/or to me.
As in Algol 60, where the BNF was admitted to be insufficient for the
_humans_ to implement the language on a *machine*, the natural language
comments were added _for_humans_. But the comments were adopted as a
part of the Ada Standard, and in AI, controversial ada issues, we see
discussion of _wording_. It's like commenting the Bible. The Disciples
keep the sacred knowledge, passing the magic via generations. And,
frankly speaking, I want to express my warmest gratitude to ARG, the
ada Rapporteur Group. This institution made Ada mature and vital and
full of life! (And even playful here at c.l.a.) But this is the only
way to have an internetional standard. I will not delve into a
discussion of all the pros and cons of English, which _actually_ is the
ISO language.
Algol 68 provides for "mapping" some purely immaterial and seemingly
non-verbal language from "conception space" where it's supposed to live
to a text space. The abstract entities corresponding to the English
keyword set MAY be mapped transitively onto some other language keyword
set.
CEA standard would allow multilingual Ada mapping, CHARACTER type
diversification, after obvious (and resolved in AI) non-ASCII
characters in comments. In my opinion, it would be of use for ada to
try to live in heavens, where the keywords are abstract entities, and
the language-like shell is a result of mapping the heavens onto the
Earth. But we live in the real cool world...
``Age Quod Agis''
Alexy V. Khrabrov
(Alexy.V....@Dartmouth.EDU)
Zak May
> Algol-68, btw, is the best by far of procedural languages. It's
> unsurpassed up to now. Every time I try to entertain myself by
> studying C++, I involuntarily compare and turn away disgusted.
You don't have to be so consistent in your love of the Sixties, sweetie -
we respect you anyway. As for your disgust towards C++, it's easy to say
it here, on comp.lang.ada. Come to comp.lang.c++ and say that.
___
Zak.
Ilya Vinarsky
Dmitrii Manin <ma...@sticky.rockefeller.edu> wrote:
>
>And recall Algol-68, which had an official Russian version. There were
>some cute equivalents for English-language terms. I don't remember
>much, but I like to say, for example, "privedenie/privodit'" instead
>of horrendous "kastnut'" ("cast").
>
>Algol-68, btw, is the best by far of procedural languages. It's
>unsurpassed up to now. Every time I try to entertain myself by
>studying C++, I involuntarily compare and turn away disgusted.
>
because of ridiculous syntax (parentheses used for the [] and ?: operators
and begin/end, among other things). Last fall, I asked Sue Graham if anyone
ever used two-level grammars for something else; she said that no, they were
too complicated. Then I remember either Kathy Yelick or Susan Graham saying
that the Algol-68 team didn't manage to define the language properly
themselves, even though they used the tools they invented.
I read somewhere that they wanted to come up with Algol 64, a successor to
Algol 60. Then it became Algol 68. Then the fun stopped at around 1975.
This is what happens when mathematicians do what engineers should be doing.
Somewhere else I read the misadventures of a PhD in physics who wasn't
hired by a company that makes toilets for yachts. Their reason - we do not
need sanitation devices of the XXI century.
For the best procedural language, I vote for Ershov's Alpha. For the best
object-oriented language, I vote for the new Norwegian Beta. For the nicest
language overall, my $0.02 go to the dataflow language Val (or VAL).
--------------------------------------------------------------------------------
Ilya Vinarsky The supreme achievement of neuron megaloplasma!
The divergent field's curl follows the gradient back, and there,
inside, transforms the matter of the question into spiritually
electromagnetic vortexes, and from them there arises the synecdoche
of answering.
Dima Volodin
>Um... Grammar with an infinite number of productions, three-pass compilation
>because of ridiculous syntax (parentheses used for the [] and ?: operators
>and begin/end, among other things). Last fall, I asked Sue Graham if anyone
>ever used two-level grammars for something else; she said that no, they were
>too complicated. Then I remember either Kathy Yelick or Susan Graham saying
>that the Algol-68 team didn't manage to define the language properly
>themselves, even though they used the tools they invented.
Bunch of bull. A68 was and is the best procedural language. And the RR
(and it's Russian translation) is simply a literary masterpiece. As of
three-pass compilation - who cares - that's what compilers are made for.
>Ilya Vinarsky The supreme achievement of neuron megaloplasma!
Dima
Robert Firth
>Um... Grammar with an infinite number of productions, three-pass compilation
>because of ridiculous syntax (parentheses used for the [] and ?: operators
>and begin/end, among other things).
Three pass? The Algol-68R compiler, from RSRE Malvern, was a one-pass
compiler for all of Algol-68 except parallel processes. The Algol-68C
compiler, from the University of Cambridge, was two pass.
And, while personally preferring the BCPL syntax
abs := x<0 -> -x, x
for conditional expressions, I still think the Algol-68 form
abs := (x<0|-x|x);
much more tasteful than the C syntax.
Fred McCall
Or better yet, don't. A lot of us aren't really interested in reading
stupid language bashing about any language. Perhaps you need to start
your own newsgroup for this kind of thead?
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
Dmitrii Manin
" Dmitrii Manin <ma...@sticky.rockefeller.edu> wrote:
" > Algol-68, btw, is the best by far of procedural languages. It's
" > unsurpassed up to now. Every time I try to entertain myself by
" > studying C++, I involuntarily compare and turn away disgusted.
"
" You don't have to be so consistent in your love of the Sixties,
sweetie -
'Sfunny, it never occurred to me this way. You may be right though :)
" we respect you anyway. As for your disgust towards C++, it's easy to say
" it here, on comp.lang.ada. Come to comp.lang.c++ and say that.
I don't have a working knowledge of it, will be kinda stupid. I'll see
what they're doing there, anyway.
Dmitrii Manin
" A lot of us aren't really interested in reading
" stupid language bashing about any language. Perhaps you need to start
" your own newsgroup for this kind of thead?
Returning this thread to Russian culture: I recalled a couple of cute
"translations": vyb/byv (=case/esac), and esli/ilse [i vse!] (=if/fi)
" "Insisting on perfect safety is for people who don't have the balls to live
" in the real world." -- Mary Shafer, NASA Ames Dryden
What about insisting on perfect relevance?
" ------------------------------------------------------------------------------
" Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
You do: see the first line of your posting.
Henry G. Baker
>for conditional expressions, I still think the Algol-68 form
> abs := (x<0|-x|x);
>much more tasteful than the C syntax.
You like that better than 'abs(x) = |x|'? I seem to recall that Vaughan
Pratt's CGOL grammar allowed such outfix (??) notations. :-)
Robert Dewar
from what he quotes, it sounds like Sue Graham (uncharactersitically for
her) is talking about something she doesn't know much about.
In fact the Algol-68 report is remarkably precise, easy to comprehend once
you have paid the (admittedly huge) price of understanding the formalism (I
always found I could answer questions easily about Algol-68), and furthermore
the report is remarkably accurate. Very few errors have been found (although
to be fair, it has not been subjected to the same scrutiny as the Ada
standard, but still, there is no way that the A68 report could generate the
long list of gaps and minor omissions that less formally written definitions
tend to generate.
Yes, the grammar is complex, but on the other hand, it is at least somewhat
attractive to have a completely precise formal definition of the static
semantics (only the dynamic semantics is defined in formal English). So the
comparison point with the 2-level grammars is the complete set of English
language statements in the RM defining the static semantics.
THe point about 3-pass compilation is plain nonsense, it is perfectly
possible to compile A68 in two passes, the parentheses cause no problem
in compilation at all. The two passes are required because A68 allows
forward references.
I might note that compiling Ada in one or even two passes gets quite tricky
because of private parts in particular.
Don't misunderstand me here. I do not advocate that we use 2-level grammars
or anything like that for defining Ada. THe troubvle with A68 is that, even
though implementors and other language experts liked the report, the reaction
of the general professional public in computer science was so extremely
negative that it certainly helped kill the language (although there were
some very nice implementations, including a complete one from CDC).
One of the lessons that Jean Ichbiah learned well from the A68 experience is
that it is vital for the defining document to at least appear to be easily
readable!
Incidentally Ersov, who was very much involved with Algol-68 [I knew him well
in my position, see below] would not, I think, have shared this dim view of
A68, and in particular, although ideas from ALpha certainly influenced A68,
I don't think he would have agreed that Alpha was superior to A68.
Disclaimer: I am not a disinterested observer in this matter. I was chairman
of WG2.1 (Algol) for many years, and also chair of the Algol-68 maintenance
committee for many years (I contributed directly to the hardware representation
standard, and the modules standards that were added to the language later).
Actually I think I am the unique link between the languages as far as someone
who has officially been on both of the relevant maintenance committees,
although there are others, in particular Goos, who have had strong and
important contacts with both languages in the past [these days Charles
Lindsey, one of the original authors of the A68 report, plays with Ada
quite a bit!]
Robert Dewar
is quite true, but it was not quite a full language compiler (and in fact
restricted forward references to a minor extent). I believe that it is the
case that any full language compiler for Algol-68 will be two pass.
Ada can be compiled in one pass (the NYU Ada-Ed compiler is a one pass
compiler, and indeed historically, this compiler helped keep the Ada design
true to its semantic intent of being one pass compilable, like Pascal).
However, in practice it is darned difficult to compile in only a single
pass.
Also pointless, there is really no reason not to take multiple passes in a
compiler. The number of passes has nothing to do with speed (there are any
number of demonstrations of this obvious fact -- one is the Realia COBOL
compiler, which is a six pass compiler that compiles well over 100,000
lines a minute on a PC -- there are plenty of one pass compilers that are
a lot slower). After all, it depends on how much you do on each pass!
Ilya Vinarsky
Robert Dewar <de...@cs.nyu.edu> wrote:
>Ilya obviously doesn't speak from first hand experience with Algol-68, and
>from what he quotes, it sounds like Sue Graham (uncharactersitically for
>her) is talking about something she doesn't know much about.
either Susan Graham, a professor at UC Berkeley whose undergraduate compilers
class I took last semester, or Kathy Yelick, in whose graduate languages class
I am enrolled now) that they couldn't define it FOR A VERY LONG TIME, not that
they couldn't do it at all. Sorry again.
>
>THe point about 3-pass compilation is plain nonsense, it is perfectly
>possible to compile A68 in two passes, the parentheses cause no problem
>in compilation at all. The two passes are required because A68 allows
>forward references.
>
I cannot remember which one) that a 3-pass compiler is required because of
the peculiar syntax. For example,
(a=b | 2 | 3) .real c
would define an array of 2 elements if a=b and 3 elements otherwise, and you
would have no idea where the clause in the parentheses fits in until you get
past it. The only Algol-68 compiler I have seen was the Leningrad State Univ.
one for IBM/370; I remember someone complain that it is slow, and I never quite
bothered to find out how many passes it has. Not that it makes much difference
nowadays.
--------------------------------------------------------------------------------
Ilya Vinarsky cogito ergo coredump - the first AI's first and last words.
Dimitri Vulis, CUNY GC Math
>In article <2o5cj1$n...@schonberg.cs.nyu.edu>,
>Robert Dewar <de...@cs.nyu.edu> wrote:
>Sorry, I made a stupid mistake in my previous post. I wanted to say (quoting
>either Susan Graham, a professor at UC Berkeley whose undergraduate compilers
>class I took last semester, or Kathy Yelick, in whose graduate languages class
>I am enrolled now) that they couldn't define it FOR A VERY LONG TIME, not that
>they couldn't do it at all. Sorry again.
private college and the first time I did it, I tried to drag in Algol and BNF
and all sorts of history and I realized that the students really didn't give
a damn about things they wouldn't be using in real life. It's better if they
can concoct an LL(1) grammar at the end of the semester and can write a simple
interpreter for a pascal-like language, than if they know useless tidbits of
trivia from here and there. Algol was my first language, but it's best buried
and forgotten. Those few who need "neat stuff" will learn in in graduate school.
Dimitri Vulis
CUNY GC Math
D...@CUNYVMS1.BITNET D...@CUNYVMS1.GC.CUNY.EDU
Disclaimer: my Usenet postings don't necessarily represent anyone's views,
especially my own and/or CUNY's.
Dik T. Winter
> because of ridiculous syntax (parentheses used for the [] and ?: operators
> and begin/end, among other things).
As Robert Firth already mentioned, one-pass compilation was possible
(although the compiler I used was seven-pass ;-), but extremely fast).
Parenthesis for [] were around since, eh when did Fortran start? But
in A68 they were optional of course.
...
> Then I remember either Kathy Yelick or Susan Graham saying
> that the Algol-68 team didn't manage to define the language properly
> themselves, even though they used the tools they invented.
So what? Do you know of any language that *is* properly defined? Whenever
you are writing a grammar there are bound to be problems, regardless of
the level of formality of the grammar. The two-level grammar of Algol 68
enabled the writers to put a lot in the grammar that is normally given over
to the semantics that are normally written down a bit informal. BTW, I
heard of a few errors indeed, but those I heard about where in the section
that defined the standard prelude/postlude, i.e. the code itself.
Of course, the original definition made some extensions introduced later
difficult (like formats vs. point-stropping).
>
> I read somewhere that they wanted to come up with Algol 64, a successor to
> Algol 60. Then it became Algol 68.
Never heard about Algol 64 (and I ought to know around where I work). You
mean Algol X.
> Then the fun stopped at around 1975.
1975? So in 1985 I was really living 10 years earlier?
> This is what happens when mathematicians do what engineers should be doing.
Let's see. Mathematicians you said? Who were the mathematicians?
Van Wijngaarden? Not at all, engineer I would say. Came from (what
is currently called) Delft Technical University. Who else did you
have in mind?
> Somewhere else I read the misadventures of a PhD in physics who wasn't
> hired by a company that makes toilets for yachts. Their reason - we do not
> need sanitation devices of the XXI century.
Did this apply to van Wijngaarden (who as far as I know had a PhD in physics)?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl
Paul L. Clark
Ilya Vinarsky <iv...@monoceros.EECS.Berkeley.EDU> wrote:
]I remember reading in one of my father's books (it has been so many years that
]I cannot remember which one) that a 3-pass compiler is required because of
]the peculiar syntax. For example,
](a=b | 2 | 3) .real c
]would define an array of 2 elements if a=b and 3 elements otherwise, and you
]would have no idea where the clause in the parentheses fits in until you get
]past it.
So ? Why do you need to know "where it fits" beforehand ?
ObAlgol-68:
They say they couldn't come up with a CF grammar to force most of the
syntactic restrictions of Algol-68.
So they designed two grammars such that correct program is
parsed by both of them. (And both parse trees provide pieces
of necessary information for generating the code).
Dik T. Winter
> ObAlgol-68:
>
> They say they couldn't come up with a CF grammar to force most of the
> syntactic restrictions of Algol-68.
> So they designed two grammars such that correct program is
> parsed by both of them. (And both parse trees provide pieces
> of necessary information for generating the code).
This is an incorrect, or at least misleading, description of two-level
grammars. The second level grammar is there to provide an infinitude
of rules for the first level grammar. This means that indeed much
semantics can be encapsulated in the grammar. For instance, rather than
defining an assignment as (simplified):
leftside := rightside
it is defined as:
ref MODE leftside := MODE rightside
where MODE comes from the second level grammar and specifies the type
system. MODE should be replaced consistently by identical productions
of MODE from the second level grammar to get a valid first grammar rule.
This indicates that
a := b
is correct if a is of 'mode' ref int and b is of 'mode' int, but not
if b is of 'mode' real. These things are normally relegated to the
semantics. (Actually the grammar of the RR (the first of these not in
the original) will check whether a and b are in scope and perform
appropriate coercion rules (casts/type conversions)).
Indeed, an attempt was made to make the grammar context free. As far
as I know it still is not completely CF, but Robert Dewar will slap me
on the fingers if I am wrong ;-).
Fred McCall
: In article <1994Apr7.1...@mksol.dseg.ti.com> mcc...@mksol.dseg.ti.com (Fred McCall) writes:
: " A lot of us aren't really interested in reading
: " stupid language bashing about any language. Perhaps you need to start
: " your own newsgroup for this kind of thead?
: Returning this thread to Russian culture: I recalled a couple of cute
: "translations": vyb/byv (=case/esac), and esli/ilse [i vse!] (=if/fi)
: " "Insisting on perfect safety is for people who don't have the balls to live
: " in the real world." -- Mary Shafer, NASA Ames Dryden
: What about insisting on perfect relevance?
*ANY* relevance would be nice. Get back to me when you find some.
: " ------------------------------------------------------------------------------
: " Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
: You do: see the first line of your posting.
No, I don't. I just report the fact. I'm hardly the first person to
express disinterest in 'language bashing' and, until the clueless learn
not to do it, I doubt that I shall be the last. Pointing out that I
have no interest in 'language bashing' and that others have expressed
the identical opinion is hardly 'speaking for others'.
Given everything I've ever seen crossposted out of soc.culture.soviet,
I'm left feeling like someone needs to come up with a kill file that
can differentiate Russian names and selectively eliminate their posts.
Is that where talk.bizarre has moved to?
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
R.A. Mendlowitz
Rybin that ANSI 1815A has been translated into Russian as a state
standard GOST 27831-88. Dr. Rybin, as mentioned by Alexy Khrabrov in
his posting, has an informative summary of the state of Ada in Russia
up to 1993. Dr. Rybin would like to submit to submit a message
concerning the Russian Ada standard to INFO-ADA. Can anyone tell me how
this can be done? I am not familiar with all the in's and out's of
networking. Somehow my request got onto INFO-ADA where Dr. Rybin
responded to it.
If anyone would like a copy of Dr. Rybin's overview "Ada in Russia" I
would be happy to e-mail a copy.
Best regards,
R.A. Mendlowitz
Michael Harrison
de...@cs.nyu.edu "Robert Dewar" writes:
>
> Noting Robert Firth's comment that the Malvern compiler was one pass. This
> is quite true, but it was not quite a full language compiler (and in fact
> restricted forward references to a minor extent). I believe that it is the
> case that any full language compiler for Algol-68 will be two pass.
>
Actually, Ian Currie said (at the IFIP Working Conference in Munich in 1970 -
see "Algol 68 Implementation - ed J E L Peck") that Malvern wrote the 68-R
compiler as a one pass compiler simply because that was the technique that
they understood: "I would not know how to set about writing a multi-pass
compiler. I would regard it as a major intellectual exercise, not the least
of which is having to work out n more intermediate codes. The writing of a
one-pass compiler, influenced us quite a lot in the subset of ALGOL 68 that
we implement."
As an amusing side-light, I remember Ian telling me that Malvern had somehow
lost all the source code for the [original] 68-R compiler for the the ICL 1900
and had for several years had to maintain it by patching the executable file!
> Ada can be compiled in one pass (the NYU Ada-Ed compiler is a one pass
> compiler, and indeed historically, this compiler helped keep the Ada design
> true to its semantic intent of being one pass compilable, like Pascal).
>
I'm a *little* suprised that you should say that. I remembered that some years
ago Ron Pierce showed that labels cause a problem.
The difficulty is that a label is implicitly declared at the end of the
(possibly implicit) declarative part of the immediately enclosing block,
subprogram body etc. Now suppose that early in the block the compiler
encounters:
Lab_Addr := Label_Name'Address;
where the label is defined some arbitrary distance further on in the source
text.
What should the compiler do?
It certainly can't emit *completed* object code immediately.
Clearly, there are various 'kludges' that can be used to get round the problem,
such as leaving it to the linker to fix up the address or just delaying
I suppose it all depends what you mean by one pass :-)
> However, in practice it is darned difficult to compile in only a single
> pass.
>
> Also pointless, there is really no reason not to take multiple passes in a
> compiler.
Hear, hear!
> The number of passes has nothing to do with speed (there are any
> number of demonstrations of this obvious fact -- one is the Realia COBOL
> compiler, which is a six pass compiler that compiles well over 100,000
> lines a minute on a PC -- there are plenty of one pass compilers that are
> a lot slower). After all, it depends on how much you do on each pass!
>
>
True, though perhaps *some* of the misconception is a hangover from the old
days when an extra pass meant physically reading and writing [a representation
of] the program to disc (or even tape!).
Programmers these days don't know they're born, with acres of memory and
address space.
--
------------------------------------------------------------------------------
Michael Harrison | The first law of system design:
Soft Silicon Limited |
| Never check for an error condition you don't
m...@zdenka.demon.co.uk | know how to handle!
------------------------------------------------------------------------------
Robert Dewar
syntactic restrictions of Algol-68.
So they designed two grammars such that correct program is
parsed by both of them. (And both parse trees provide pieces
of necessary information for generating the code).
This is nonsense. Algol-68 is defined by a two-level grammar not because of
any special difficulties with the language, but because this is the particular
formalism used to precisely and formally specify the static semantics. Note
by comparison that the definition of Ada does not even attempt this, it uses
natural language for this purpose. The context free grammar of Algol-68 is
conventional, and fully comparable to that used in other similar languages.
Of course, as in Ada etc. this grammar accepts many programs that are
semantically wrong.
The second level of the A68 grammar will only parse programs that are
correct BOTH syntactically and (statically) semantically. In other words
all issues like overloading, visibility, etc are handled by the grammar.
There are no special parsing or compilation problems in A68 - overall, having
investigated both languages in some detail, I would say that Ada is harder
to compile, but not by a huge margin.
Whether or not this kind of formalism is desirable is a question that is
pretty much language independent. THe advantage of the informal Ada approach
is that people can read it, but it is of course less precise. The advantage
of the A68 approach is that it is very precise (very few errors have been
discovered, in comparison with the Ada RM). THe disadvantage is that (almost)
no one can read it.
This disadvantage is substantial. First it means that few read it (that may
at least partly account for the fact that fewer errors have been found).
Second, people who do try to read it give up and get disgusted. It is fair
to blame a substantial part of the "failure" of Alogol-68 on this
phenomenon.
I can say in my own case that I was first interested in doing an A68 compiler
in 1969, but I couldn't understand the document at all, and I gave up till
several years later when I read Ian Currie's short and very accessible
introduction to his compiler. Later I became fully familiar with the report,
but the story on A68 might have been different if I and other implementors
had understood enough to jump in earlier (indeed Ian Currie who was one
of the few A68 implementors, had great success in England with his compilers,
too bad they were for peculiar ICL machines that never made any impact outside
England -- where people were forced to buy them!)
wem...@fmsb.cca.cr.rockwell.com
In article <766104...@zdenka.demon.co.uk>, m...@zdenka.demon.co.uk (Michael Harrison) writes:
>In article <2o5cq7$o...@schonberg.cs.nyu.edu>
> de...@cs.nyu.edu "Robert Dewar" writes:
>>
>> Ada can be compiled in one pass (the NYU Ada-Ed compiler is a one pass
>> compiler, and indeed historically, this compiler helped keep the Ada design
>> true to its semantic intent of being one pass compilable, like Pascal).
>>
>> However, in practice it is darned difficult to compile in only a single
>> pass.
>>
>> Also pointless, there is really no reason not to take multiple passes in a
>> compiler.
>>
>> The number of passes has nothing to do with speed (there are any
>> number of demonstrations of this obvious fact -- one is the Realia COBOL
>> compiler, which is a six pass compiler that compiles well over 100,000
>> lines a minute on a PC -- there are plenty of one pass compilers that are
>> a lot slower). After all, it depends on how much you do on each pass!
>>
>>
>
>True, though perhaps *some* of the misconception is a hangover from the old
>days when an extra pass meant physically reading and writing [a representation
>of] the program to disc (or even tape!).
>
>Programmers these days don't know they're born, with acres of memory and
>address space.
Multiple pass compilers certainly have a greater potential to be slower than
one pass compilers simply because the intermediate code for the ENTIRE
compilation unit must be generated, stored, and the reprocessed. I don't
care if you are storing it on paper tape or completely in the processor's
cache memory, it must be stored SOMEWHERE and then reprocessed. This takes
time.
In general, the more passes a compiler has, the slower it will be. I think
you will find a direct correlation between these (sure there are notable
exceptions).
More time should have been spent making it EASY to write a one-pass Ada
compiler rather than putting in stupid constructs like GOTO statements that
do nothing but cause compiler writers headaches when having to deal with
things like label'address. If this language had been smaller, then maybe we
wouldn't now be arguing about whether it is dying and how many job openings
are there for Ada vs. C.
-Wayne
Alexy V. Khrabrov
mcc...@mksol.dseg.ti.com (Fred McCall) writes:
> Given everything I've ever seen crossposted out of soc.culture.soviet,
> I'm left feeling like someone needs to come up with a kill file that
> can differentiate Russian names and selectively eliminate their posts.
Fortunately, you don't want to kill Russians themselves,
> I'm left feeling like someone needs
probably
>the balls to live
>in the real world." -- Mary Shafer, NASA Ames Dryden.
``Age quo agis''
Alexy V. Khrabrov
(Alexy.V....@Dartmouth.EDU)
Alexy V. Khrabrov
mcc...@mksol.dseg.ti.com (Fred McCall) writes,
Re: Russian Version of Ada Programming Language Standard,
> a kill file that can differentiate Russian names [...]
Is that what your programming about?.. Differentiate from what?.. Why
differentiate vs. say integrate or negate or take a square root?
> *ANY* relevance would be nice. Get back to me when you find some.
''Age quod agis''
Alexy V. Khrabrov
(Alexy.V....@Dartmouth.EDU)
Henry G. Baker
>In article <766104...@zdenka.demon.co.uk>, m...@zdenka.demon.co.uk (Michael Harrison) writes:
>>In article <2o5cq7$o...@schonberg.cs.nyu.edu>
>> de...@cs.nyu.edu "Robert Dewar" writes:
>>> Ada can be compiled in one pass (the NYU Ada-Ed compiler is a one pass
>>> compiler, and indeed historically, this compiler helped keep the Ada design
>>> true to its semantic intent of being one pass compilable, like Pascal).
A 'multi-pass' compiler does not necessarily have to store the entire
program in between passes, at least the way one of the poster suggested.
A multi-pass compiler may make multiple passes over a small portion of
the program before going onto the next small portion of the program. Unless
you're in dire need of interprocedural optimization, the object code for
one portion can be output before the next portion is processed. Ada83
appears to have been designed with this possibility in mind.
I think that the lack of sophistication on this particular point is the
cause for some horrendously large VM consumptions and horrendously long
compile times for some well-known Ada compilers (you know who you are).
Charles H. Sampson
>In general, the more passes a compiler has, the slower it will be. I think
>you will find a direct correlation between these (sure there are notable
>exceptions).
>
>More time should have been spent making it EASY to write a one-pass Ada
>compiler rather than putting in stupid constructs like GOTO statements that
>do nothing but cause compiler writers headaches when having to deal with
>things like label'address. If this language had been smaller, then maybe we
>wouldn't now be arguing about whether it is dying and how many job openings
>are there for Ada vs. C.
All fine and good, but remember that the one-pass compiler requirement
was only one of many requirements imposed on the designers of Ada. I would
imagine that most considered it to be one of the least significant -- one
that could be let go in a crunch. As far as the goto, don't forget when
Ada was designed. We all know now that you can program quite successfully
in Ada without the goto (I haven't used one yet) but the issue wasn't that
clear in the late '70s. Its inclusion was also a requirement, because of
fear that the structured control constructs would prove inadequate.
As for the issue of speed of one-pass compilers, let's first agree
that a pass involves looking at the entire program in some representation.
By this definition, the usual technique for patching up forwarded refer-
enced labels is not a pass because it only involves manipulating an auxil-
iary data structure. In general, the purpose of a compiler pass is to make
life simpler for subsequent passes. One-pass compilers, even though they
aren't saddled with a multi-pass compiler's expense of performing program
transformations, tend to have complicated algorithms because of the ugly
form of the only program representation they have: the source code. Execu-
tion of these algorithms may prove more expensive than first doing a trans-
formation and then executing a simpler algorithm.
Charlie
-mlc-+Schilling J.
>you will find a direct correlation between these (sure there are notable
>exceptions).
>
For Ada's major intended market (real-time systems) compilers have to do
heavy optimization. Such optimizers mean one-pass compilers are a non-starter:
not only will the optimizers be separate passes, but the time spent in them
will often dominate the overall compilation time.
The bad press Ada got in the early days was more due to large and slow
generated code, rather than large and slow compilers (although was there
some of that too).
--
Jonathan Schilling
Novell, Unix Systems Group (Unix System Laboratories)
j...@summit.novell.com
Robert Firth
>As far as the goto, don't forget when
>Ada was designed. We all know now that you can program quite successfully
>in Ada without the goto (I haven't used one yet) but the issue wasn't that
>clear in the late '70s.
Another rationale for including the goto was that its absence would
make it much harder to generate Ada automatically from 4GL or other
higher-level representations. Consider for instance generating an
optimal decision table of finite-state machine without a goto.
Also, the presence of the goto does not rule out one-pass compilation.
All you have to do is require that labels be declared at the beginning
of the relevant scope, same as everything else. Of course, nobody
else argues for this!
wem...@fmsb.cca.cr.rockwell.com
In article <1994Apr15....@sei.cmu.edu>, fi...@sei.cmu.edu (Robert Firth) writes:
|>Another rationale for including the goto was that its absence would
|>make it much harder to generate Ada automatically from 4GL or other
|>higher-level representations. Consider for instance generating an
|>optimal decision table of finite-state machine without a goto.
Robert I think you missed my point. I don't disagree that you can devise a
perfectly legitimate use for almost ANY language feature. I could just as
easily argue that case statements should allow for the option to drop through
to the next case option.
The point is, you have to decide what in a language is required and what is
not. In my opinion, Ada is not doing well because it has too many unnecessary
features. I would get rid of GOTO's and subunits (now that we have child
packages).
We need an Ada subset that can be a commercial success.
-Wayne
Bill Kinnersley
In article <2okd26...@marble.summit.novell.com>,
-mlc-+Schilling J. <j...@summit.novell.com> wrote:
: In article <1994Apr13.2...@zodiac.cca.rockwell.com> wem...@fmsb.cca.cr.rockwell.com () writes:
: >In general, the more passes a compiler has, the slower it will be. I think
: >you will find a direct correlation between these (sure there are notable
: >exceptions).
: >
: >More time should have been spent making it EASY to write a one-pass Ada [...]
:
: For Ada's major intended market (real-time systems) compilers have to do
: heavy optimization. Such optimizers mean one-pass compilers are a non-starter:
: not only will the optimizers be separate passes, but the time spent in them
: will often dominate the overall compilation time.
:
: The bad press Ada got in the early days was more due to large and slow
: generated code, rather than large and slow compilers (although was there
: some of that too).
Early days? The following comments concerning the speed of current Ada
compilers was recently posted to comp.compilers: ^^^^^^^
>Newsgroups: comp.compilers
>Subject: Re: Why do we still assemble?
>Message-ID: <94-0...@comp.compilers>
>From: hba...@netcom.com (Henry G. Baker)
>Date: Fri, 8 Apr 1994 17:17:36 GMT
>References: <94-0...@comp.compilers> <94-0...@comp.compilers>
>Organization: nil
>
>
>I personally made the rounds at a recent Ada conference, and compiled and
>ran the same 5,000 line benchmark Ada program on as many systems in the
>booths that would allow me. The differences were absolutely astounding.
>The compilers of companies T,V, and A, who shall remain anonymous ;-),
> each took between 30 and 40 _mega_ bytes of swap space, and took about 15
>_minutes_ to compile on what appeared to be sparcstations. The compiler
>of Company M took only about 1+ megabytes of swap space, and compiled in
>about 2 minutes on a 66MHz 486 with a several megabyte disk buffer. (The
>486 only had 16 Mbytes of real memory, and the disk light was flashing, so
>it wasn't running entirely in RAM.)
>
>All of this compile time might be useful if the compiled code actually ran
>faster. But it didn't. All of the compiled programs executed in nearly
>the same time. (No, it wasn't I/O or FP bound; it is a CPU/memory
>intensive integer benchmark.)
>
>While one of the Unix compilers was running, I did a periodic 'ps' to find
>out what was taking so much time. Apparently the very first phase which
>did lexical analysis, parsing and building a syntax tree took most of the
>time.
>
>I was also told by a British company who built a large Ada system with HW
>and SW from company D, that his 180,000 line system took an entire _week_
>(i.e., around 168 hours) to compile. He was forced to begin using binary
>patches....
>
>These compilers come from established companies with some of the best
>people in the business. What gives?
>
>
--
--Bill Kinnersley
bi...@hawk.cs.ukans.edu
226 Transfer complete.
Ted Dennison
|> In article <1994Apr13.2...@zodiac.cca.rockwell.com> wem...@fmsb.cca.cr.rockwell.com () writes:
|>
|> that could be let go in a crunch. As far as the goto, don't forget when
|> Ada was designed. We all know now that you can program quite successfully
|> in Ada without the goto (I haven't used one yet) but the issue wasn't that
|> clear in the late '70s. Its inclusion was also a requirement, because of
|> fear that the structured control constructs would prove inadequate.
Do you have some actual knowlege of this, or is it just speculation? The reason
I ask is that according to Stephen J. Young, "They (goto's and labels) are
included in Ada to allow programs to be written which automatically translate
other programming languages into Ada." (from page 50, An Introduction to Ada,
second revised edition).
I don't know what special knowledge (if any) Dr. Young has of the original
design, but this sounds more plausable to me.
T.E.D.
wem...@fmsb.cca.cr.rockwell.com
I didn't write that. I was quoting someone else. I was arguing that GOTO's
never should have been in the language in the first place.
I have always believed like C.A.R Hoare that Ada would be VERY successful if
it wasn't so damn big and complicated. There is no one feature you can point
to that is so bad. They are just straws on the camel's back. Let's get rid
of this straw...
-Wayne
Robert Dewar
designers for over 30 years. Anyone who has programmed in Algol-60 perfectly
well understands that in normal cases, gotos are not to be used. Indeed I and
many European colleagues were rather amused by the extraordinary reaction to
Dkikstra's letter "Gotos considered harmful". This letter certainly had no
new observations, it merely stated what was broadly known by competent
Algol programmers for years. Yet in Fortran oriented US, it caused something
of a sensation. Most odd!
Furthermore, it is more characterstic of what is really an overreaction on
this issue in the US to seriously suggest banning the goto completely. There
are situations in which the goto used judiciously is helpful. A notable
example is the modeling of a finite state machine where the program counter
is used to represent the state. I know that Jean Ichibiah once looked at
some of my code and was surprised to find liberal use of goto statements.
He questioned this, and I pointed out that it was a finite state machine,
and he immediately agreed that this was a perfectly reasonable use.
So please don't speculate on why the goto was not left out of Ada, and also
don't be overpround of never having used a goto. It is of course possible
to program anything without gotos, and good programmers rarely use the goto
statement, but if you take pride in never ever having used a goto, it is
quite possible that you are overreacting, and may miss doing things neatly
in those rare situations where gotos are appropriate and helpful.
Adam Beneschan
I don't think I've come across one of these rare situations lately; in
any case, I can't recall using any GOTO's since I started programming
in Ada six years ago. However, even though I don't use them, I agree
with Robert that banning them would be wrong. When I first saw a
description of Modula-2, it really rubbed me the wrong way that GOTO
statements had been removed. I got the impression that Wirth wanted
to decide for everyone else what programming style to use. (There
were other language features that added to that impression, some
having to do with letter case, I seem to recall.) Such a restriction
might be appropriate for a teaching language, perhaps, when you don't
want to get students into the habit of using GOTO. But for a language
designer to dictate to experienced professional programmers what is
"good" and "bad" practice is---well, arrogant and somewhat
paternalistic.
Anyway, somebody needs to write a sequel to Dijkstra's essay:
"Fanatical Persecution of Gotos Considered Harmful".
-- Adam
Michael Feldman
>de...@cs.nyu.edu (Robert Dewar) writes:
>
[snip]
>Anyway, somebody needs to write a sequel to Dijkstra's essay:
>"Fanatical Persecution of Gotos Considered Harmful".
I'll go along with this if we generalize the title to "Fanaticism
Considered Harmful." We seem destined in this business to swing from
extreme to extreme, with moderation, intelligence, and plain ol' common
sense being the increasingly rare exception. Why do we DO this?
By the way - if I remember my history correctly, Dijkstra did _not_
give that title to his letter. Originally he submitted it as a paper
with some other title; the editor, realizing it was good stuff,
suggested it be published as a letter to get it in print (much) faster.
The editor titled it, as editors of daily newspapers also do with letters.
Is this right, or is my old gray memory playing tricks again?
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfel...@seas.gwu.edu (Internet)
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------
George Jansen
>>
>[snip]
>
>>Anyway, somebody needs to write a sequel to Dijkstra's essay:
>>"Fanatical Persecution of Gotos Considered Harmful".
>
>I'll go along with this if we generalize the title to "Fanaticism
>Considered Harmful." We seem destined in this business to swing from
>extreme to extreme, with moderation, intelligence, and plain ol' common
>sense being the increasingly rare exception. Why do we DO this?
Actually, "Fanatical Persecution etc." was written, but Knuth called it
"Structured Programming with Got; you can find it in a number of places,
Knuth's _Literate Programming_, and a collection by Yourdon of essays on
software engineering.
Extremes are almost as much fun, and considerably less work. Years ago I was
a copy editor, and was entertained by the number of persons who were sure that
the schools quit teaching how to distinguish "which" from "that" the year
they graduated; in some cases this seemed to have been the only thing they
had learned about prose. Jacques Barzun has an essay on this & other sins of
copy editors in _A Word or Two Before You Go_.
The writing of software has some kinship with the writing of prose--
Stroustrup touches on this in _The C++ Programming Language_. So do the
some of the pitfalls, apparently.
George Jansen
Robert Dewar
It is hard to believe that it was originally submitted as a paper. If so,
and if I had refereed it, I would have turned it down on the grounds that
there was nothing original. Of course as a letter, it certainly was a useful
contribution at the time.
Robert I. Eachus
> Do you have some actual knowlege of this, or is it just
> speculation? The reason I ask is that according to Stephen J.
> Young, "They (goto's and labels) are included in Ada to allow
> programs to be written which automatically translate other
> programming languages into Ada." (from page 50, An Introduction to
> Ada, second revised edition).
I'd say, and you can ask others involved, that both are right.
While "automatic translation" tools were certainly a driver, it was
more a feeling that parser and scanner generation tools would need
gotos to build efficient state machine drivers. (The other languages
in this case are context-free grammars and regular expressions.)
In my case, the only Ada gotos I ever wrote outside compiler tests
were in exactly such drivers or in hand implementations of finite
state machines.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
wem...@fmsb.cca.cr.rockwell.com
If you were to take a small poll of "ordinary" Ada engineers (not language
experts), I think you would find less than 10% who could write a GOTO
statement in Ada without consulting a manual. This is due to the fact
that they have never seen a label and do not know the syntax. We have
long since passed the point of "being proud of not using a GOTO" to the
point of not knowing how to do it...
My argument for excluding GOTO's from the language is not "fanatical
persecution of the GOTO", rather it is an argument for simplicity in a
language design.
The Ada GOTO is a simple construct to implement in an Ada compiler, but it
is not trivial. The only GOTO I ever wrote was to demonstrate that an Ada
compiler had incorrectly implemented it and that the ACVC test suite had
failed to detect the problem. This test was submitted for inclusion in the
ACVC test suite.
Can anyone guess what the problem was (hint: it was submitted as a tasking
test).
-Wayne
Richard A. O'Keefe
>Back when everyone was up in arms about GOTO, someone wrote a magazine
>article proposing that GO TO be eliminated and replaced with a new
>construct, COME FROM.
The COME FROM statement was actually implemented in Intercal.
For anyone who might be in the world's least comprehensible programming
language, here's how you can get an Intercal compiler.
language: INTERCAL
package: C-INTERCAL
version: 0.9
parts: compiler, library, documentation
author: Eric S. Raymond <e...@snark.thyrsus.com>
how to get: ftp pub/intercal/intercal0.9.* from sequoia.lle.rochester.edu
description: INTERCAL is possibly the most elaborate and long-lived joke
in the history of programming languages. It was first designed
by Don Woods and Jim Lyons in 1972 as a deliberate attempt
to produce a language as unlike any existing one as possible.
The manual, describing features of horrifying uniqueness,
became an underground classic. ESR wrote C-INTERCAL in 1990
as a break from editing _The_New_Hacker's_Dictionary_, adding
to it the first implementation of COME FROM under its own name.
The compiler has since been maintained and extended by an
international community of technomasochists. The distribution
includes extensive documentation and a program library.
C-INTERCAL is actually an INTERCAL-to-C source translator which
then calls the local C compiler to generate a binary. The code
is thus quite portable.
contact: Steve Swales <st...@bat.lle.rochester.edu>
updated: 1993/05/20
If ever there was an opposite to Ada, Intercal's _it_.
--
Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
"C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie.
Adam Beneschan
> >>
> >[snip]
> >
> >>Anyway, somebody needs to write a sequel to Dijkstra's essay:
> >>"Fanatical Persecution of Gotos Considered Harmful".
> >
> >I'll go along with this if we generalize the title to "Fanaticism
> >Considered Harmful." We seem destined in this business to swing from
> >extreme to extreme, with moderation, intelligence, and plain ol' common
> >sense being the increasingly rare exception. Why do we DO this?
>
> Actually, "Fanatical Persecution etc." was written, but Knuth called it
> "Structured Programming with Got; you can find it in a number of places,
> Knuth's _Literate Programming_, and a collection by Yourdon of essays on
> software engineering.
Back when everyone was up in arms about GOTO, someone wrote a magazine
article proposing that GO TO be eliminated and replaced with a new
construct, COME FROM. The use (in Fortran) would be something like
this:
X=2*X
10 Y=Y+X
. . .
. . .
COME FROM 10
Y = Y+3*X
. . .
The effect would be that whenever the program hit line 10, it would
automatically branch to the COME FROM 10 statement. Since this was
Fortran, the author also included examples of the conditional COME
FROM, computed COME FROM, and assigned COME FROM. The article was a
really wonderful bit of humor.
-- Adam
Charles H. Sampson
Robert Dewar <de...@cs.nyu.edu> wrote:
>
> [Goto-related information, including an example of its occasional useful-
> ness, deleted.]
>
>So please don't speculate on why the goto was not left out of Ada, and also
>don't be overpround of never having used a goto. It is of course possible
>to program anything without gotos, and good programmers rarely use the goto
>statement, but if you take pride in never ever having used a goto, it is
>quite possible that you are overreacting, and may miss doing things neatly
>in those rare situations where gotos are appropriate and helpful.
>
not needed, parenthetically remarking that I hadn't used one yet, I want to
say that that remark was not prideful, it was just a statement of fact. Like
Robert, I believe in using the tools I have at my disposal to do the job at
hand. It just happens that none of my jobs have required me to use the goto
yet.
To illustrate my position, I have written CMS-2 code that uses the so-
called abnormal exit from procedures fairly extensively, although in a very
controlled manner. This controlled use gave me a pretty good simulation of
Ada's exceptions, with all the readability benefits of the latter, in par-
ticular lack of clutter in the procedure when attempting to bail out after
having detected the exceptional condition.
One of the joys of working in Ada is being able to do good software en-
gineering while using the language as it was intended, without resorting to
a number of constraints that can only be verified by extra-language means.
Charlie
Charles H. Sampson
Ted Dennison <denn...@romulus13.DAB.GE.COM> wrote:
>In article <1994Apr14....@nosc.mil>, sam...@nosc.mil (me) writes:
>
>> ... As far as the goto, don't forget when
>> Ada was designed. We all know now that you can program quite successfully
>> in Ada without the goto (I haven't used one yet) but the issue wasn't that
>> clear in the late '70s. Its inclusion was also a requirement, because of
>> fear that the structured control constructs would prove inadequate.
>
>Do you have some actual knowlege of this, or is it just speculation? The reason
>I ask is that according to Stephen J. Young, "They (goto's and labels) are
>included in Ada to allow programs to be written which automatically translate
>other programming languages into Ada." (from page 50, An Introduction to Ada,
>second revised edition).
>
>I don't know what special knowledge (if any) Dr. Young has of the original
>design, but this sounds more plausable to me.
I was relying on memory, having been involved in the Ada effort since
the mid-70s (it was then commonly called DoD-1). It happens that I have
just stumbled across my copies of the Tinman and Ironman requirements and
both Dr. Young and I are right. Ironman isn't much help because it simply
lists requirements but Tinman also contains some rationale. The rationale
for the goto requirement begins: "The 'GO TO' is a machine level capability
which is still needed to fill in any gaps which might remain in the choice
of structured control primitives, to provide compatibility for translitter-
ating programs written in older languages, and because of the wide familiar-
ity with its use." The remainder of the rationale adds some restrictions,
such as outlaing switches or label variables. It also says that the goto
should only transfer control to a label at the same scope level; that re-
quirement was removed from Ironman.
Charlie
Robb Nebbe
:
: My argument for excluding GOTO's from the language is not "fanatical
: persecution of the GOTO", rather it is an argument for simplicity in a
: language design.
: -Wayne
If you look at a state machine I think a goto is the right abstraction
to use. The typical view of a state machine is that control is
tranfered out of a state to another state and does not come back unless
it is explicitly transfered back as a result of some input.
A subprogram call implies to me that the transfer of control is only
temporary which doesn't match the abstraction of a state machine as
well. I have seen state machines implemented without a goto and I
have always found that it makes the code less clear.
- Robb Nebbe
Tucker Taft
Robb Nebbe <ne...@lglsun.epfl.ch> wrote:
>If you look at a state machine I think a goto is the right abstraction
>to use. The typical view of a state machine is that control is
>tranfered out of a state to another state and does not come back unless
>it is explicitly transfered back as a result of some input.
Not to interfere in this love fest for the much maligned goto ;-),
but I respectfully disagree that a goto is the right abstraction
for a state machine. A case statement in a loop seems much
preferable, with the state represented explicitly in a variable
of an enumeration type.
A case statement in a loop may not be as *efficient*, but it
seems to be a better *abstraction,* as it better captures the
basic iterative nature of a state machine, and provides an explicit
(e.g. printable) representation of the state, rather than having
to bury it in the program counter. It is also easier to
debug, since you can at any point ask to see what is the
current state. You can also calculate the appropriate "next state"
in a subprogram and return it to the main line, allowing you
to cut down on the amount of code required directly in the
main subprogram of the state machine.
>... I have seen state machines implemented without a goto and I
>have always found that it makes the code less clear.
Less clear than a case statement in a loop? I'm a bit surprised.
>- Robb Nebbe
S. Tucker Taft s...@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA 02138
P.S. In any case, gotos were not worth banning in Ada 9X, as the popular
programming culture has effectively removed them from most code,
and getting the last few out would be unduly painful and create
an unnecessary hullabaloo about what is now a relatively minor issue. -T
P.P.S. Here is a simple example of what I mean by a case statement
in a loop:
type State_Enum is (Undefined, Initial, ..., Final);
procedure State_Machine(Start_State : State_Enum := Initial) is
Current_State : State_Enum := Start_State;
Next_State : State_Enum := Undefined;
begin
while Current_State /= Final loop
case Current_State is
when Initial =>
...
Next_State := ...;
...
when ... =>
...
end case;
Current_State := Next_State;
Next_State := Undefined;
end loop;
end State_Machine;
-T
wem...@fmsb.cca.cr.rockwell.com
In article <CovxE...@inmet.camb.inmet.com>,
s...@spock.camb.inmet.com (Tucker Taft) writes:
>A case statement in a loop seems much
>preferable, with the state represented explicitly in a variable
>of an enumeration type.
I agree this has always been my choice for state machines. I've never
seen anyone try to implement it with GOTO's in Ada. As a matter of fact,
I've never seen anyone use GOTO's for ANYTHING in Ada (hence this debate).
I think you're right that GOTO's needed to be left in Ada-9X for
backward compatibility.
When Ada-9X was being designed, there was a concern that the language
would be too large. This resulted in the "zero-based budget" approach
which seems to me to have had little effect. Nearly all the features
listed in the DEC 91 mapping document were eventually implemented or
replaced. I understand that this document had already been trimmed
down substantially (unfortunately eliminating variable strings, but
that's another topic...).
During this process there was a letter (I believe from Christine
Anderson) that indicated that serious attention should be put forward
towards developing an Ada language subset.
Did anything ever come of this?
I know it is painful to part with "your favorite language feature"
including (as we have seen) even the GOTO statement. I believe, however,
that a truly successful language has to start with a solid, simple core.
Wouldn't a well designed Ada subset be able to compete with 'C' more
effectively?
-Wayne.
David Weller
>Back when everyone was up in arms about GOTO, someone wrote a magazine
>article proposing that GO TO be eliminated and replaced with a new
>construct, COME FROM. The use (in Fortran) would be something like
>this:
>automatically branch to the COME FROM 10 statement. Since this was
>Fortran, the author also included examples of the conditional COME
>FROM, computed COME FROM, and assigned COME FROM. The article was a
>really wonderful bit of humor.
>
It was an April (for April Fool's) edition of Communications of the
ACM. My fuzzy brain believes it was somewhere in the 84-87 time
frame.
--
Ada 9X:Try it again for the first time! Free Ada compilers:cs.nyu.edu(pub/gnat).
Free Ada goodies: wuarchive.wustl.edu (/languages/ada). Free ref. manual and
other docs: ajpo.sei.cmu.edu (/public/ada9x). || Member:
The Ada WWW Server is http://lglwww.epfl.ch/Ada/ || Team Ada, Team OS/2
Robert Dewar
. loop
. case State is
.
. when State_1 =>
. ...
. State := 4;
.
. ...
. end case;
. end loop;
and
. <<State1>>
. ...
. goto State_4;
.
. ...
The choice between these is an aesthetic one. I much prefer the second form
with the gotos. I think it is easier to debug, and understand, and is a more
faithful representation of the typical picture of a state machine with the
gotos being the arrows and the labeled chunks of code the circles.
But it's a matter of taste for sure, I can live with the first form, I just
find it less clear. That is especially true if people start playing games
like "State := State * 2 + 1" in a subprocedure, which of course is nasty
style, but has been observed from time to time :-) Of course in the second
form, no such games are possible.
I have often asked gathered groups of people, say students in a class, which
of these two they prefer, and my experience is that at least a few years ago,
there is a constituency for both styles, with gotos having the majority.
Either form is acceptable really, the only unacceptable attitude is one which
finds either of these forms unacceptable, and it is particularly irritating
for someone to assume that the goto form is horrible because they have been
told that gotos are horrible.
Robert Dewar
Wayne says:
"I agree this has always been my choice for state machines. I've never
seen anyone try to implement it with GOTO's in Ada. As a matter of fact,
I've never seen anyone use GOTO's for ANYTHING in Ada (hence this debate).
If you care to do a little FTP'ing from nyu, you may end this long search
for a GOTO in Ada :-)
The scanner for GNAT is 2421 lines long, approximately half of which are
comments or blank lines. There are 287 gotos in this code.
Yes, of course it could be written without gotos (there is after all a theorem
to that effect), but I doubt it would clarify the code!
And as far as making a subset of Ada to compete with C, this seems a lost
cause. C is rapidly becoming obsolete, to be replaced by C++, which is a very
large language, comparable to Ada 9X in size and complexity (some would say
more complex). I think any substantial subtractions from 9X would make it
much less attractive.
(to be fair, some of the gotos in the scanner are efficiency oriented, and
many of them come from code that certainly SHOULD have been generated by an
automoton -- the checks for keywords -- but actually the automaton that
generated this code had initials RBKD :-)
wem...@fmsb.cca.cr.rockwell.com
In article <2pkdo6$8...@schonberg.cs.nyu.edu>,
de...@cs.nyu.edu (Robert Dewar) writes:
>The scanner for GNAT is 2421 lines long, approximately half of which are
>comments or blank lines. There are 287 gotos in this code.
I didn't realize this is such a sensitive subject. I have never stated that
using GOTO's is bad practice. I'm sure I would be perfectly comfortable
with the GNAT scanner. Scanner's I have designed do not have GOTO's. Are
they "better"? NO, just different.
>And as far as making a subset of Ada to compete with C, this seems a lost
>cause. C is rapidly becoming obsolete, to be replaced by C++, which is a very
>large language, comparable to Ada 9X in size and complexity (some would say
>more complex). I think any substantial subtractions from 9X would make it
>much less attractive.
I've come to realize that you are right. The time has passed where an Ada
subset would have propelled Ada into the mainstream. Sometimes I get a
little discouraged when I see C and C++ used for applications that I had
thought Ada was the perfect choice for. It's easy to blame this on Ada
being a difficult language to implement.
There is too much Ada code already written for a subset to succeed. Maybe
your free compiler will go a long way towards changing this situation.
Rockwell has a corporate policy against using the GNAT compiler because of
a concern about the license agreement (I've heard this actually originated
from the GCC compiler). I believe it had something to do with the inclusion
of the RTS in products could cause a loss of copyright protection for the
product.
That seems odd to me. Do you know anything about that?
-Wayne.
david.c.willett
Ummm.... I think we should pause here an ask which form compiles into the
most efficient binary code. Clearly, the answer will vary with processor
architecture and compiler, but efficiency of execution is a discriminator
at this stage (I agree with Robert that either form captures the algorithm).
In most state machines of real significance (at least the ones I've dealt
with :^) ) performance is a paramount concern, of greater interest than
debugging. That is certainly not true in general, but it's true of a
large enough number of state machine programs to constitute a subclass
of problems.
<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Dave Willett AT&T Advanced Technology Systems
Greensboro, NC USA
The real cowboy's the one in the middle, 'cause he don't have to drive,
and he don't have to mess with the gate.
-- Michael Martin Muphy "Cowboy Logic"
Robb Nebbe
: of an enumeration type.
Having done quite a bit a state machine design in hardware using state
transistion tables (which is also an iterative view of a state machine)
I always found this approach to be less intuitive but certainly not
difficult.
: A case statement in a loop may not be as *efficient*, but it
: seems to be a better *abstraction,*
I would say that it is less efficient because it is not as close to the
abstraction of a state machine. Obviously there are all kinds of other
considerations to take into account which may justify choosing a case
statement in a loop as the better *implementation* of a state machine.
My point was that a goto is a completely different abstraction than a
subprogram call since the flow of control does not return; a state
machine is the only case I have ever found where this is what I
wanted. (I did have to look the syntax up for labels and the goto)
Personally I don't consider a case statement in a loop to be the most
intuitive view of a state machine. (probably because I don't recognize
their "basic iterative nature" :-)
- Robb Nebbe
Robert Dewar
Probably the goto form will compile into the more efficient code. The real
question is whether the compiler is clever enough to transform the case code
into the equivalent goto code. Remember that unconditional gotos are efficient
on almost all machines (they are for example, free on the IBM RS6000
architecure for this kind of application).
I certainly don't know of any current architecture where a straightforward
translation of the loop case would result in efficient code, and the
transformation to the goto form is not entirely trivial by any means.
Richard Kenner
>Rockwell has a corporate policy against using the GNAT compiler because of
>a concern about the license agreement (I've heard this actually originated
>from the GCC compiler). I believe it had something to do with the inclusion
>of the RTS in products could cause a loss of copyright protection for the
>product.
>
>That seems odd to me. Do you know anything about that?
It's not the least bit odd. Many people have had that misunderstanding
about the GPL.
Robert Dewar
to understand that there are no barriers to the use of GNAT or GCC for the
compilation of proprietary products.
Rather than argue the legalisms, the easiest thing is to point to NextStep,
which as you might have noticed is NOT in the public domain :-) being at
this stage the only capital of Next Inc.
NextStep is entirely written using Objective C (one of the available front
ends for GCC)
All GNAT library modules are released under the GNU Public Library License,
carefully crafted to make sure that it does not intefere with this principle.
As I said at the start, any company can make any policy they like, but I
would hope that a potentially damaging policy like this one (which presumably
makes it hard for Rockwell engineers to use GNAT for its intended purpose as
an early available transition tool) is not based on casual misunderstanding!
Michael Harrison
dwe...@Starbase.NeoSoft.COM "David Weller" writes:
> >
> Yes it was. Lots of semi-credible technical details, as I recall.
> It was an April (for April Fool's) edition of Communications of the
> ACM. My fuzzy brain believes it was somewhere in the 84-87 time
> frame.
>
>
My memory may be playing tricks (or should that be parity errors :-) ) but I
believe the original article was in SigPlan in about 1976/7.
That still being the era of Algol68, I remember another spoof proposal about
extending A68's 'if' ... 'fi' approach to FORTRAN with:
SUBROUTINE
...
ENITOURBUS.
>
--
------------------------------------------------------------------------------
Michael Harrison | The first law of system design:
Soft Silicon Limited |
| Never check for an error condition you don't
m...@zdenka.demon.co.uk | know how to handle!
------------------------------------------------------------------------------
Lance Kibblewhite
In article <2pkcr6$8...@schonberg.cs.nyu.edu>, de...@cs.nyu.edu (Robert
machine (for instance on a stack) before changing state, so that it may be
restored later. In other situations, the initial state can vary. Both
of these are more difficult to do with 'goto' model, as opposed to the
'case' model.
Another variation is where the next state is determined algorithmically.
In the 'goto' model, this requires an construct similar to the 'computed
goto'. In situations where this computation is performed in a subprogram,
a pseudo state variable (which may only represent of subset of the
possible states) is often necessary, resulting in a hybrid of the
two models.
For flexibility of implementation and maintainability, I find the 'case'
model to be more suitable.
-- Lance.
Kenneth Almquist
> Well ROckwell is free to do whatever it likes, but it is important for people
> to understand that there are no barriers to the use of GNAT or GCC for the
> compilation of proprietary products.
>
>
> All GNAT library modules are released under the GNU Public Library License,
> carefully crafted to make sure that it does not intefere with this principle.
You haven't read the GNU Public Library License very carefully if you
believe this. The License requires that you permit the recipient to
modify the library and relink. As the License itself notes,
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
> Rather than argue the legalisms, the easiest thing is to point to NextStep,
> which as you might have noticed is NOT in the public domain :-) being at
> this stage the only capital of Next Inc.
NextStep presumably doesn't use the GNU C Library. (Also, I believe
that some GNU software was made available to UC Berkeley without the
normal license restrictions and may have spread from there, but I don't
know the details.)
Kenneth Almquist
Richard Kenner
>You haven't read the GNU Public Library License very carefully if you
>believe this. The License requires that you permit the recipient to
>modify the library and relink.
Of course. Otherwise stating that the library was free software wouldn't
have much meaning. However this in no way affects the copyright
status of the rest of the code.
> It may happen that this requirement contradicts the license
> restrictions of other proprietary libraries that do not normally
> accompany the operating system. Such a contradiction means you cannot
> use both them and the Library together in an executable that you
> distribute.
This is a clause talking about a hypothetical possiblity of what might
be in the license agreements of some proprietary libraries. Do you know
of any specific libraries with which there would be such a conflict?
>NextStep presumably doesn't use the GNU C Library.
No, because the GNU C library is very recent. But since NextStep is,
I thought, a library itself, there's no conflict at all.
(Also, I believe that some GNU software was made available to UC Berkeley
>without the normal license restrictions and may have spread from there,
>but I don't know the details.)
I've never heard about this and would be very surprised if it were the case.
Robert Dewar
interesting. At the machine level of course, saving the state is trivial,
it is just a matter of saving the PC, but this is one of those facilities
which high level languages have abstracted away from us (another example
of such a lack is the carry flag).
SO there are indeed a few cases in which, due to facilities removed from
Ada (quite deliberately to increase the level of abstraction), we have trouble
writing in Ada. Saving the state of a [nice clear goto-encoded] state machine
is one of these [writing an efficient multiple precision arithmetic package
is another!]
Another example is the issue of whether to use recursion or an explicit stack
for control of a recursive algorithm. Most people at the Ada level would
find the recursion clearer, but if you overlay, as Lance did, the requirement
to save the state of the computation, you have a heck of a time saving the
invocation stack in Ada (though of course it would be easy to do in
assembler).
Once I had a recursive descent parser coded in Ada in a conventional manner.
THen a requirement came along later to save and restore the state of the
parser.
The easiest (!) way I found of doing this was to write a preprocessor that
converted the whole parser into one gigantic network of gotos with an
explicit stack, and then saved the state by saving the program counter, in
the form of an index used in a case jump.
[well the original source stayed clean :-)]
Mike Frame
...
: Yes it was. Lots of semi-credible technical details, as I recall.
: It was an April (for April Fool's) edition of Communications of the
: ACM. My fuzzy brain believes it was somewhere in the 84-87 time
: frame.
I believe it actually appeared in Datamation (at least originally) and
it was probably in the 1970's. As I remember there were a number of
people who took the article (by R. Clarke?) seriously.i
Mike
k...@rational.com
: (entertaining how long this totally inappropriate subject line has survived:-)
Of course it is very unlikely that the code which produces the branching
will have any significant impact on the execution of the state machine.
I'm of the opinion that the logic executed in the verious state is likely
to dominate. If the logic of branching to the verious states dominates
then one would have to have a *very very* sloaw processor before it would
make any difference. However, it is and interesting discussion (though
with a very strange title).
Kent Mitchell
Rational Software Corporation
Kenneth Almquist
> This is a clause talking about a hypothetical possiblity of what might
> be in the license agreements of some proprietary libraries. Do you know
> of any specific libraries with which there would be such a conflict?
Yes. For example, I have a license agreement for a C compiler from Computer
Innovations, Inc. in front of me. It gives me permission to "create User
Programs using the Program Material" and says that "such User Programs may
include copies of code derived from the Source Libraries and/or Object
Libraries. User Programs...are not subject to any usage restriction."
Other uses of the "Program Material" are limited to a single machine.
I'm surprised you ask for an example, though, because clauses like this
are quite common. The quote talks about "proprietary libraries". If you
can distribute copies of a library to other people without paying a fee,
the library can hardly be said to be proprietary. There are proprietary
libraries distributed under terms which prohibit any distribution of
programs which use the proprietary library unless you buy a copy of the
library for each machine that the program is run on. But such libraries
are rare. I cannot think of any other case in which there would not be a
conflict between the GLPL and the terms of a proprietary library.
Kenneth Almquist
Robert I. Eachus
> Not to interfere in this love fest for the much maligned goto ;-),
> but I respectfully disagree that a goto is the right abstraction
> for a state machine. A case statement in a loop seems much
> preferable, with the state represented explicitly in a variable
> of an enumeration type.
But you still want gotos in the case statement version! The only
non-test cases where I have written gotos in Ada have been state
machines. But there are often cases where you want to do "branch tail
merging" in the source code--not to make sure the compiler does it
right, but you often have 42 cases which do the normal end of
iteration steps such as advancing one token, and a much smaller number
that don't. You can either wrap those actions in a procedure, or put
them in the natural position, and use gotos for the exceptions. This
is especially true when there is a series of actions, and you may have
several different entry points.
Another case where I used a goto in a state machine was in a driver
for the Multics LALR tool generated tables. Most of the shift table
entries were tuples of the form (token, next state). The last entry
in such a list was normally (default, next state), but for compaction
purposes, if two tables had identical tails the tool merged them. If
one was a subset of the other, no problem, but sometimes we needed a
"rump" with a last entry which indicated to continue with another
table. Rather than write the driver as a loop which was iterated at
most once and in only these rare cases, using a goto was much easier
to understand.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
Richard Kenner
>Yes. For example, I have a license agreement for a C compiler from Computer
>Innovations, Inc. in front of me. It gives me permission to "create User
>Programs using the Program Material" and says that "such User Programs may
>include copies of code derived from the Source Libraries and/or Object
>Libraries. User Programs...are not subject to any usage restriction."
>Other uses of the "Program Material" are limited to a single machine.
>
>I'm surprised you ask for an example, though, because clauses like this
>are quite common. The quote talks about "proprietary libraries". If you
>can distribute copies of a library to other people without paying a fee,
>the library can hardly be said to be proprietary.
This may or may not conflict depending on the definition of User
Programs. If I take all object files, including that of the library
and link them all together into a partially-linked "user program"
which can then be relinked with GLPL'ed libraries (i.e. ld -x -r), I
don't see that it's necessarily violating those restrictions.
Besides, even if it did, it isn't a problem since I could still
distribute my own objects and make the purchase of the proprierty
library up to the customer. I still have trouble conceiving a
situation where there would be an unresolvable conflict.
However, for GNAT I should point out that those parts of the library
that are not explicitly called by user programs will not have the
restrictions in question applied to them, only those that *are*
explicitly called and which could therefore be replaced by
proprietary versions if needed.