wm@tekchips.UUCP (Wm Leler) (12/20/83)
The only completely untyped language I know of (not that that
means there aren't others) is BCPL. It's the language where an
integer is a character is a procedure is an array is a pointer,
is a float, ... I loved it.
Wm Leler 503/627-5151
wm.Tektronix@Rand-relay
{ucbvax|allegra|decvax}!tektronix!wm
{cbosg|pur-ee|unc}!teklabs!wmstevesu@azure.UUCP (Steve Summit) (12/21/83)
Wm Leler claims the only completely untyped language he knows of
is BCPL. Funny thing about BCPL. It's the predecessor of a
little-known language called B, which is the predecessor of a
language you might have heard of called C.
(BCPL stands for Basic Computer Programming Language. I doubt
it's related to BASIC.)
Steve Summit
tektronix!tekmdp!stevesujdd@allegra.UUCP (John DeTreville) (12/27/83)
Wm Leler claims the only completely untyped language he knows of
is BCPL. Funny thing about BCPL. It's the predecessor of a
little-known language called B, which is the predecessor of a
language you might have heard of called C.
(BCPL stands for Basic Computer Programming Language. I doubt
it's related to BASIC.)
Steve Summit
tektronix!tekmdp!stevesu
Well, actually, BCPL stands for "Basic CPL", where CPL stood for "Combined
Programming Language". BCPL was a stripped-down version of CPL.
Cheers,
John ("Old-Time BCPL Hacker") DeTreville
Bell Labs, Murray Hilltjt@kobold.UUCP (T.J.Teixeira) (12/29/83)
BCPL explicitly assumes that memory is word addressed, and all values
(integers, pointers, floating point numbers) can be represented in a
word. This works out fine for machines addressed this way. e.g.
PDP-10's, GE-645 (now Honeywell 6180's -- i.e. Multics), older
minicomputers (if you ignore floating point).
BCPL is not good for character strings. Strings are stored in a dense
representation, but there is no good way to reference individual
characters from BCPL, aside from shifting and masking. Then again,
that's unavoidable on a word-addressed machine.
If memory is byte addressed rather than word addressed, BCPL is less
attractive. The compiler is either painfully constructing byte
addresses, or you drop the requirement that adding 1 to an address gets
you the address of the next "word". The first is inefficient for the
operations lv and rv (like unary & and * in C), but a toss-up for real
array accesses (to evaluate E1[E2] in C you would normally scale E2 by
the size of the object pointed to by E1 (or vice versa -- as has been
pointed out E1[E2] is equivalent to E2[E1]) -- in BCPL you would just
add E1 to E2 and scale the sum). The second approach causes most
existing BCPL programs to break.
In addition, on a byte-addressed machine the lack of an operator to
perform byte addressing seems more annoying and inefficient.
I never used B, but my Sixth Edition C Reference Manual states:
C is a computer language based on the earlier language B. The
languages and their compilers differ in two major ways: C
introduces the notion of types, and defines appropriate extra
syntax and semantics; also, C on the PDP-11 is a true compiler,
producing machine code where B produced interpreted code.
I suspect that one of the original reasons for introducing data types
was because those data values required different amount of storage. In
order to do address scaling automatically, it is necessary to keep
track of the types of pointers. Once you have any types, you might as
well implement float and double rather than introduce special floating
point operators (e.g. $+, $-, $* and $/ were floating point operations
in BCPL).
For a long time, type checking in C was very weak. Numeric types
(char, int, float and double) were widened or narrowed inside an
expression, but pointer types were not checked (i.e. for structure
references). The types of function arguments are still not checked by
the compiler.
Curiously enough, BCPL and C are complementary languages in the sense
that machines that are good for BCPL are not good for C, and vice
versa. BCPL is difficult to implement on a byte-addressed machine, and
character arrays in C are hard to implement on word-addressed machine.
I suspect that if byte-addressed minicomputers hadn't come around (i.e.
if Ken Thompson and Dennis Ritchie had stayed with the PDP-7/9/15
line), UNIX would have been written in BCPL.
P.S. BCPL stands for Basic *Combined* Programming Language, not *Computer*
language and is related to CPL (Combined Programming Language). I
don't know anything about CPL (the references I have for it are to a
1963 issue of The Computer Journal), but the abstract for one version
of BCPL Reference Manual (from BBN) states:
BCPL is a a simple recursive programming language designed for
compiler writing and system programming; it was derived from true
CPL (Combined Programming Language) by removing those features of
the full language which make compilation difficult, namely, the
type and mode matching rules and the variety of definition
structures with their associated scope rules.
Whaddya mean, difficult to implement? It's only taken ten years, and
we almost have most of it working.
Seriously, does anyone out there know how close modern C is to CPL?
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200rde@ukc.UUCP (01/12/84)
Some more information about BCPL. Since the mid 1970s, the operator
'%' (percent) has been supported by virtually all compilers. This
provides a partial solution to the byte addressing problem.
x%y addresses the byte at offset y from word address x
(on a VAX, this would be x*4+y, get it?)
The byte addressing problems are still there, but they cause
relatively few problems. They only rear their ugly head when calling
operating systems, and when evaluating addresses using the LV (or @)
address operator. Indexing is done by using the scaling operations
provided by most hardware these days (e.g. index mode on a VAX). I have
written a 4.1BSD compiler, and the code isn't bad at all (even though I
say it myself).
About CPL. The project died because there were too many people
involved, not all in the same geographical location, with insufficient
time to spend on development.
The language isn't so very different from C, although (as one would
expect) it is rather less terse. There are more control structures (no
increased functionality, but it probably makes programs more readable
than some of the awful for(....) constructs I have seen). Minor
differences include things like multiple assignment that creates
temporaries if there would be interaction....
a, b := b, a
actually swaps a and b!
If anyone is really interested, I could dig out more....
Bob Eager
Computing Laboratory,
University of Kent,
Canterbury, UK.
CT2 7NF.
(secretary, BCPL User Group!!)