Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <1366@optima.cs.arizona.edu>
Date: 1 Apr 91 22:11:44 GMT
Sender: news@cs.arizona.edu
Lines: 98

In article  <1991Mar29.191210.9369@maths.nott.ac.uk> Dr A. N. Walker writes:
]In article <1124@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman)
]writes:
]
]>It will take a great deal of evidence to convince me that the Algol
]>committee members were so ignorant that they actually argued over the
]>implementability of anything in Algol 60.  There is nothing in the
]>language that any knowledgeable person would doubt can be implemented.
]
]	Whoa!  There are two different meanings of "implement" and three
]different meanings of "Algol" that are being mixed up, if not actually
]confused.

Nope.  I said Algol 60 because I meant Algol 60.  And _I'm_ not
confusing "implement" with "compile", although it looked like you
were.

]...  In response to my queries, he asserted that he
]intended the earliest Algol tradition [ie Algol 58, or IAL], denied
]intending Algol 60, and couldn't remember whether he'd actually read
]the Algol 58 report.  ["I rest my case m'lud."  However, I cannot resist.]

In the first place, I said the earliest "tradition", not "language"
[ie not Algol 58 or IAL].  What I meant was the design philosophy that
resulted in Algol 60, including all the decisions that were made
before that point.  The most important decision being that the
language should be compilable.  Whether the designers ever mentioned
this decision, or were even aware of it, I don't know.  But I do know
that this was an implicit part of the Algol 60 design.  I'm comparing
Algol 60 to Lisp and SNOBOL, not to FORTRAN and C.

As to the sarcasm: for your information I _have_ read the Algol 60
report and the Algol 68 report, and enough other information to think
I have a good feel for the way programming languages evolved.  This is
not a refereed forum, and I'll not accept being chastized for not
making a literature review before posting.

]Algol 60:  Intended primarily as a descriptive language, and certainly
]	not efficient (call by name, dynamic typing
                                     -------
I assume you meant "static".

]	No "clever assembler" of the
]	period would have included recursive procedures, or dynamic
]	arrays, for example, as indeed Fortran didn't.

Both features can be compiled.  They were less efficient on the
machines of the day.

]	Strings and other useful things *are* in Algol 60 [2 out of 5
]isn't bad!].

I should have been more specific: concatenatable, sectionable strings
with automatic storage management.  Those pathetic things that
statically typed languages call "strings" are really character arrays.

]  In 1960, the other things were scarcely recognised as
]being useful:

Mathematicians had thought they were useful for decades or centuries,
and were the designers of Lisp and SNOBOL also recognized their
importance.  They just didn't fit machine architectures well, so
languages designers who were worried about efficiency didn't deal with
them.

Basically, there are two traditions of programming language design:
Type A designers are concerned about efficiency and type B designers
are concerned about expressiveness.  Historically, you could tell
these designs apart because type A languages were compiled and type B
languages were interpreted (this no longer holds).  Type A languages
were designed with the idea that there should be a fairly direct
mapping from the language to machine languages.  Thus they needed
static typing, functions that were defined before compilation, and
simple data structures that could be mapped onto machine memory
directly.

Type B language designers didn't worry about efficiency, and created
languages with no simple relationship to machine languages (thus
needing to implement them with interpreters).  Type B languages almost
universally have dynamic typing and generalized data structures with
automatic storage management, most also have dynamically created
functions.

Within each camp, there were different levels of concern for
efficiency, but within the type A camp there was always this strong
aversion to any feature that would require a lot of runtime support.
Algol 60 clearly and unambiguously fits into type A.  It is true that
_within the type A camp_, they were somewhat cavalier about
efficiency, but they still didn't introduce anything that required a
great deal of runtime support.  In relationship to the programming
language community as a whole, they were extremely concerned with
efficiency.  Only someone who is unfamiliar of the huge type B
community would claim that Algol 60 was designed without regard to
efficiency.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman