--
__________________________________________________________________
Ilja Bedner Software Engineer
Hewlett Packard Company Information Networks Division
Unix Mail : il...@cup.hp.com (408) 447-2609
--
Patric Jonsson,d88...@nada.kth.se;"always mount a scratch monkey"-jargon file.
Well, I can't read Sussman's and Steele's minds, but 'Conniver' was called
'Conniver', and it has 8 letters, so I think that they could have used
'Schemer', which only has 7. So I think that the letter-cutoff thing is
apocryphal. Sorry if I've ruined a good story for you. In the end, of
course, the good story always wins out over the truth. So I guess when
it comes to religious beliefs -- e.g., computer languages -- there is no
objective reality. Whatever appears in 'Hackers' (part I, II, III, ...)
becomes the gospel for future generations.
Now here's a _true_ story for you. ITS had a bug which depended
literally on the phase of the moon (the Earth's Moon, not David Moon).
Someone had written a program to calculate the phase of the moon, and
someone else decided that it would be a good herald line. Now the
program that printed out the phase of the moon would write out a line
whose length varied depending upon the phase of the moon.
Unfortunately, a very long line would do something very bad and/or
bizarre, so every once in a while, but dependent upon the phase of the
moon, the system would exhibit this bug.
Henry> So, 'Scheme' is based on the American connotation of the word
Henry> 'scheme' (not the British), and this connotation is more
Henry> along the lines of 'connive'.
i always heard that it was 'Schemer' but since ITS had 6 letter
filenames, it got shortened to just 'scheme'
-bri
In article <BDC.94Ma...@blackjack.ai.mit.edu> b...@blackjack.ai.mit.edu (Brian D. Carlstrom) writes:
>i always heard that it was 'Schemer' but since ITS had 6 letter
>filenames, it got shortened to just 'scheme'
Well, I can't read Sussman's and Steele's minds, but 'Conniver' was called
'Conniver', and it has 8 letters, so I think that they could have used
'Schemer', which only has 7. So I think that the letter-cutoff thing is
apocryphal. Sorry if I've ruined a good story for you. In the end, of
I'm not in your KILL file, am I? The 6-letter story is in fact true.
Look up my previous posting on this subject for a full reference, but
Steele writes it himself in his HOPL paper with Gabriel ``The
Evolution of Lisp'' (p. 18):
``Sussman and Steele were pleased with this toy actor implementation
and named it `Schemer' in the expectation that it might develop into
another AI language in the tradition of Planner and Conniver.
However, the ITS operating system had a 6-character limitation on file
names and so the name was truncated to simply `Scheme' and that name
stuck.''
Of course, there wasn't any ITS file named ``CONNIVER'' for the
obvious reason you named, but unlike in the case of Scheme this didn't
lead to a name truncation. There is no law of nature that
automatically renames a language when the file system doesn't let you
have a compiler by that name. Otherwise, we wouldn't be stuck with
FORTRAN but FORTRA...
--
-Matthias
Anyway, Schemer (not Scheme) was very slow. So David and I later implemented a
chronological backtracking version of nondeterministic Common Lisp which we
called Screamer, since it was supposed to `scream'.
Jeff
In article <BDC.94Ma...@blackjack.ai.mit.edu> b...@blackjack.ai.mit.edu (Brian D. Carlstrom) writes:
>>>>>> Henry G Baker writes:
> Henry> So, 'Scheme' is based on the American connotation of the word
> Henry> 'scheme' (not the British), and this connotation is more
> Henry> along the lines of 'connive'.
>i always heard that it was 'Schemer' but since ITS had 6 letter
>filenames, it got shortened to just 'scheme'
Well, I can't read Sussman's and Steele's minds, but 'Conniver' was called
'Conniver', and it has 8 letters, so I think that they could have used
'Schemer', which only has 7. So I think that the letter-cutoff thing is
apocryphal. Sorry if I've ruined a good story for you. In the end, of
course, the good story always wins out over the truth. So I guess when
it comes to religious beliefs -- e.g., computer languages -- there is no
objective reality. Whatever appears in 'Hackers' (part I, II, III, ...)
becomes the gospel for future generations.
Sorry, Henry, but your guess is incorrect. However, your
initial premise was sound: indeed you cannot read our minds!
ITS did have a 6-character filename restriction. "Conniver",
you may recall, was shortened to "CNVR" for this purpose,
as "Planner" before it was shortened to "PNLR". I cannot
explain why we did not use the shortened form "SCHMR";
instead we used "SCHEME" and eventually that name stuck.
We were just as happy when it turned out that Scheme did
not seem to be an AI language in the Planner/Conniver series
after all.
On the more general topic of objective reality and "religious
issues", consider these:
Doubting Thomas refused to believe in the resurrection
of Jesus until he saw for himself; Jesus reportedly remarked,
"Have you believed because you have seen me? Blessed are those
who have not seen and yet believe." Of those who read this
account (John 20:24-29) as handed down to us by various paths,
some believe and some do not.
I have measured the charge on the electron myself, several times,
using Millikan's method; it always came out to about 1/3 of the
usually stated amount. However, I believe in the accepted value
*despite* my own experience, because I accept the testimony of
others, whose skill I respect, as trustworthy. Is my belief
in the value of the charge on the electron objective? Is yours?
And now I claim that the Story of the Name of Scheme is true,
and I testify to this as an eyewitness. I would be mildly
interested to know how many will choose to believe me, and how
many will not. However, I will prefer baking homemade pizza and
playing my piano and hacking to losing sleep worrying over whether
people believe this story.
I think we all rely on testimony rather than objectivity more
than most people care to admit. In any case, a certain amount
of skepticism is healthy.
Now here's a _true_ story for you. ITS had a bug which depended
literally on the phase of the moon (the Earth's Moon, not David Moon).
Someone had written a program to calculate the phase of the moon, and
someone else decided that it would be a good herald line. Now the
program that printed out the phase of the moon would write out a line
whose length varied depending upon the phase of the moon.
Unfortunately, a very long line would do something very bad and/or
bizarre, so every once in a while, but dependent upon the phase of the
moon, the system would exhibit this bug.
I was there on that one as well; it was my code (a Lisp program) that
had the bug. It printed the phase-of-moon info on one line, preceded
by a semicolon, so it would have the form of a Lisp comment. (This
was in a data file to be read by another Lisp program, so it was
important that it be printed as a comment.) Unfortunately, the Lisp
system of the day was in the habit of helpfully inserting a newline
whenever the current line reached 80 characters. Very occasionally
the phase-of-moon info, plus semicolon, would exceed 80 characters
and the excess would appear on a second line, without a semicolon,
thus producing a Lisp data file of incorrect format.
It should be kept in mind that printing the phase of the moon on
program listings was by then already a very old ITS tradition.
I had merely adapted the code from TECO for use by Lisp code.
You will find the bug discussed in the entry "phase of the moon" in
the original "Hacker's Dictionary" of 1983 (now out of print) and
also in its successor:
Raymond, Eric S. (ed.), with assistance and illustrations by Guy L.
Steele Jr. The New Hacker's Dictionary, second edition. MIT Press
(Cambridge, Massachusetts, 1993). ISBN 0-262-68079-3.
--Guy Steele
>> i always heard that it was 'Schemer' but since ITS had 6 letter
>> filenames, it got shortened to just 'scheme'
Henry> Well, I can't read Sussman's and Steele's minds, but
Henry> 'Conniver' was called 'Conniver', and it has 8 letters, so I
Henry> think that they could have used 'Schemer', which only has 7.
Henry> So I think that the letter-cutoff thing is apocryphal. Sorry
Henry> if I've ruined a good story for you.
consider i heard this from Sussman's group here at MIT, i tend to lend
it more legitimacy than other sources. It might have even been in
Steeles talk on the history of lisp
-bri
Here I stand corrected; I can do no other.
>I have measured the charge on the electron myself, several times,
>using Millikan's method; it always came out to about 1/3 of the
>usually stated amount.
ITS truncated your electron charge measurements, too? :-) :-)
Raymond says:
"The first paper edition of the Jargon File (Steele-1983) included an example
of one of the timestamp lines that exhibited this bug, but the typesetter
'corrected' it. This has since been described as the phase-of-the-moon-bug
bug."
This story is also true. I have the original proofs of the Hacker's
Dictionary in front of me (how's that for authenticity?), and they look like
this: (the line breaks are exactly as in the page proofs).
Steele incorporated this routine into a LISP pro-
gram that, when it wrote out a file, would print a 'timestamp''
at the top that looked something like this:
;THE MOON IS 1 DAY, 20 HOURS, 42 MINUTES, AND 54 SECONDS
PAST THE FIRST QUARTER.
; THE SUN IS 41*44'1' NORTH OF EAST, 35*7'26' BELOW THE
HORIZON
; THAT MEANS IT IS NOW 2:21 AM ON WEDNESDAY, MARCH 23,
1983.
(A calulation of the position of the sun was also included for
additional HACK VALUE. The asterisk was used in lieue of a "de-
grees" symbol to indicate angles.) Occasionally the first line of the
message would be too long and would overflow onto the next line
like this:
; THE MOON IS 2 DAYS, 17 HOURS, 20 MINUTES, AND 45 SE-
CONDS PAST THE FIRST QUARTER
; THE SUN IS 18*17'47' WEST OF NORTH, 44*56'42' BELOW THE
HORIZON
; THAT MEANS IT IS NOW 10:59 PM ON WEDNESDAY, MARCH
23, 1983.
When the file was later read back in, the program would BARF.
The length of the first line depended on the precise time when the
timestamp was printed, and so the bug literally depended on the
phase of the moon!
--Mitch
Mitchell Wand Internet: wa...@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/USER/wand Fax: (617) 373 5121
Now that this subject has been opened, I re-read the HOPL paper on the
evolution of Lisp, including the part about Scheme(r).
This HOPL account of Scheme(r) appears to be correct as far as it
goes, but I would like to add some additional points about Scheme(r)
v. Actors.
HOPL re Scheme(r):
"Hewitt's model was object-oriented (and influenced by Smalltalk)."
I think that it would be more accurate to say that Smalltalk and
Actors were mutually influenced by one another. The earliest
Smalltalks had some incredibly ugly semantics about objects deciding
how many arguments they would take from an argument stream, which
probably came from a faint Forth influence. I think Carl's Actors
stuff convinced the Smalltalk people that this desparately needed to
be cleaned up.
Quoting from Hewitt & Smith "Towards a Programming Apprentic", IEEE
Trans. SW Engrg, March _1975_:
"[We have been] developing a universal communication primitive (called
actor transmission) to enable all control structures to be recognized
as a pattern of passing messages."
"In November 1972, A. Kay gave a seminar at MIT in which he emphasized
the importance of using intentional definitions of data structures and
of passing messages to them such as was done to a limited extent for
the 'procedural data structures' in the lambda calculus languages of
Landin, Evans, and Reynolds and extensively in Simula-67. His
argument was that only the data type itself really "knows" how to
implement any given operation. We had previously given some attention
to procedural data structures in our own research. For example we
already had known how to implement the Lisp cons function in the
lambda calculus. However, we were under the misconception that
although procedural data-structures had certain advantages that they
were too inefficient for practical use."
"Kay's lecture struck a responsive note because of this previous
history. We immediately saw how to use his idea to extend the concept
of procedural embedding".
"Kay proposed a language called Smalltalk with a token stream oriented
interpreter to implement these ideas...."
"By December 1972, we succeeded in generalizing the message mechanism
of Smalltalk and Simula-67; the port mechanism of Krutar, Balzer, and
Mitchell; and the previous Call statement of Planner-71 to a universal
communication mechanism. Our generalization solved the control structure
problems that Hewitt pointed out to Kay in the design of Smalltalk."
"Actor transmission subsumes the operations of function call, function
return, and co-routine call."
HOPL article re Scheme(r):
"Because Sussman had just been studying Algol [ref], he suggested
starting with a lexically scoped dialect of Lisp."
Once again, I can't read Sussman's mind, but _every_ version of Actors
that I saw in 1973-75 was already lexically scoped. In fact,
continuation-passing style -- used heavily in Actors -- doesn't make
very much sense with dynamic scoping. (Most of the people at MIT
became aware of CPS by means of Michael Fischer's 1972 paper, which
was recently republished in Lisp & Symbolic Computation.)
HOPL:
"Then came a crucial discovery ... [a long paragraph on function
application and actor application being the same thing]".
Well, this may have been a discovery to Sussman, but it was already
well known by everyone in the Actor group, including Carl himself,
Brian Smith, Richard Steiger, etc., because they had been building
interpreters for Actors for several years. Steiger's Master's Thesis
was published in June, 1974.
HOPL:
"Lambda: The Ultimate Imperative [Steele, 1976a]" demonstrated how a
wide variety of control structure ideas could be modeled in Scheme".
Steele's paper essentially redoes Hewitt's "Viewing Control Structures
as Patterns of Passing Messages" WP92, AI Lab, Dec. 1975, but in
Scheme. My copy of Steele's 3/76 'Imperative' does not reference
Hewitt's 12/75 'Patterns' paper, but does reference a much more
obscure earlier version in LNCS 19, from 1974, "Behavioral Semantics
of Non-recursive Control Structures".
I think that the contributions of Scheme were not continuations or
lexical scoping, per se, but a re-application of these Actors ideas
back into Lisp syntax and Lisp programming styles. Actors had pretty
much abandoned traditional Lisp syntax, and preferred the CPS style
over the functional style. It was also heavily reflective, although
that term wasn't invented until later. Actors at that time was also
not a concrete language, but a set of ideas which changed and evolved
at a great rate. In order to have a _programming language_, the ideas
had to be made concrete and stable. Scheme did this with elegance and
grace.
>I have measured the charge on the electron myself, several times,
>using Millikan's method; it always came out to about 1/3 of the
>usually stated amount. However, I believe in the accepted value
>*despite* my own experience, because I accept the testimony of
>others, whose skill I respect, as trustworthy. Is my belief
>in the value of the charge on the electron objective? Is yours?
Are you serious? That is really weird! The point is that it seems
that Milikan himself reported a number of measurements that were
precisely 1/3 of the correct value--in addition to many more
measurements that gave the latter. These relatively few anomalous
measurements have never been explained. Why 1/3? Why not 1/2, or
some irrational number? No one knows.
These anomalous measurements were re-discussed about 10 years ago
(?) when there were rumours that a group at Stanford discovered free
quarks (that carry 1/3 of the charge of the electron) in a very
different experiment.
Omar.
g...@think.COM (Guy Steele) writes:
Omar.
Actually, a group at Caltech did find quarks using a varient of the
Millikan Oil Drop experiment in the early 80's. I believe the paper
was published in 1983, but my memory could be faulty on the date.
--------------------
Morry Katz
ka...@cs.stanford.edu
--------------------