BCPL in the new millenium (was: Proposal3: Make $_ avalididentifier cha...

Alan Kay Alan.Kay at disney.com
Fri Jun 2 20:26:49 UTC 2000


BCPL had a long history with ARPA and PARC. Jim Curry, at Lincoln Labs in
the 60's, then at Utah, then at PARC, was one of the earliest bootstrappers
of BCPL. The workhorse at PARC for the first 2 years was the Data General
NOVA, which however lacked an efficient semihighlevel language to program
with (the Algol on it was too slow and too hermetically sealed). So Jim
bootstrapped one of the versions of BCPL to the NOVA.
    The bootstrapping was interesting. BCPL had a bytecoded representation
of itself (descended like all such from the legendary Burrough's B5000).
One first wrote an interpreter for these byte codes, in this case in NOVA
assembler. This got BCPL running, but slowly. One then started using BCPL
to make a back end native code generator for the new machine. Once this
started running the bootstrap was done and BCPL was pretty efficient. One
of the architectures that was emulated by the Alto when it started running
in 1973 was the NOVA (but with a 16 bit address space instead of the NOVA's
15-bit space). And BCPL was used for some of the Alto programming.
     Quite a bit of the non-Smalltalk and non-Lisp software was done in
BCPL, including one of the several operating systems, and BRAVO, which was
the embryo of what is now called MS Word.

BTW, the really interesting language back then was BCPL's "god" -- called
CPL -- originally for: Cambridge Programming Language (later "Combined Prog
Lang"), with many of the major design ideas by Christopher Strachey and
Peter Landin. It was an attempt to merge Algol and Lisp, and had many
really profound insights into the nature of programming and metaprogramming.
     BCPL was the tiniest shadow of this language, but it was easily
implementable, whereas CPL was very difficult to implement (and in fact
never quite got above threshold).

Cheers to all,

Alan

P.S. At PARC we had complete control over our character sets and fonts, and
very little interest in ASCII...  Smalltalk-72 could deal with sequences of
keywords with spaces in between them -- and it was a "zero-overhead"
extensible language: that is, each class was defined as a syntactic
recognizer of the messages it could receive in a very straightforward
manner. The resulting syntax was much more "scripting like" than
Smalltalk-80 (and even quite a few of today's "scripting languages").
     This was a really good idea for a while, but started to degenerate
into a Tower of Babel via poor choices for syntactic forms in the heat of
programming (even by good programmers).
     Smalltalk-76 (by Dan) was a really interesting meeting ground between
a compilable and a readable syntax. Smalltalk-80's syntax (I believe) could
have adopted a stronger theory of uniformity that would have yielded more
pleasing results (I don't like it).
     I still like the idea of easy syntactic extension (and most of the
possible routes to metaprogramming), but experience seems to say that
"making it easy" should not generally be the same as "put it at the same
level of expression". There should be "fences" that you have to jump over
to do the metaprogramming, but once jumped, the metaprogramming should be
easy and not obscure .... (Squeak needs a LOT OF WORK to be in accord with
this principle.)

------

At 9:55 AM -0800 6/2/00, Dwight Hughes wrote:
>"David T. Lewis" wrote:
>>
>> On Thu, Jun 01, 2000 at 09:29:28PM -0700, Dan Ingalls wrote:
>> >
>> > You might be interested to know that the very first occurrence of a
>>Smalltalk-to-C (-like language) was a translator from Smalltalk to BCPL
>>that Ted Kaehler, Glenn Krasner and I did way back when we were at Xerox.
>> >
>>
>> Thanks, that's very interesting. I actually had no idea that people on
>> this list would even know what BCPL is, so I am surpised now to learn
>> that it is part of Smalltalk's earlier history.
>
>A further reference is the "Alto BCPL Manual" online at
>http://www.spies.com/~aek/alto/index.html .
>
>-- Dwight







More information about the Squeak-dev mailing list