Discussion:
BCPL in the new millenium (was: Proposal3: Make $_ a valid identifier cha...
JArchibald at aol.com ()
2012-01-28 10:05:49 UTC
Permalink
=> 6/1/00 12:32:49 AM EDT, ***@mail.msen.com =>
<< Here you will find an up to date BCPL manual, portable implementions of
BCPL and MCPL, a Tripos command shell, and other fun stuff. >>

Far out! Now BCPL is a language (other than Smalltalk) that you can get
excited about. Its successors (C and C++) can't hold a candle to the original
BCPL (IMHO).

Jerry.
____________________________

Jerry L. Archibald
systemObjectivesIncorporated
____________________________
Dan Ingalls
2012-01-28 10:21:35 UTC
Permalink
Post by JArchibald at aol.com ()
<< Here you will find an up to date BCPL manual, portable implementions of
BCPL and MCPL, a Tripos command shell, and other fun stuff. >>
Far out! Now BCPL is a language (other than Smalltalk) that you can get
excited about. Its successors (C and C++) can't hold a candle to the original
BCPL (IMHO).
Agreed.

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.

We had designed this (pretty cool) virtual memory named LOOM (see the Green Book) that used 16-bit internal pointers, but 32-bit external pointers. This meant that if we could get it to work, we could just bolt it onto the existing (then fastest in the world) Dorado Smalltalk. Ted wrote the whole thing in Smalltalk, and arranged to run two images back-to-back, one with the LOOM VM code in it, the other with then normal Smalltalk image. When there was a fault in the normal image, it entered a primitive that emerged on the other side to handle the fault.

When this all finally worked (it did!), we wanted to speed it up, and make it smaller by rewriting it in BCPL (BCPL was supported on all the Xerox hardware at the time). Ted had written a lot of it in the style of SLANG -- ie, Smalltalk as machine code -- so instead of starting over, we just changed the prettyPrinter to emit valid BCPL code for about 80% of what was there. We did that in a day, and then Ted and Glenn finished the translation by hand.

- Dan
Alan Kay
2012-01-28 10:32:25 UTC
Permalink
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.)

------
Post by Dan Ingalls
Post by Dan Ingalls
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
Loading...