Talk:CPL (programming language)
|WikiProject Computer science|
This is consistent with my understanding of the CPL rumours too. I'm not sure there ever was a complete working CPL compiler. Shame there doesn't seem to much documentary evidence for this stuff. --drj
The story when I was at Cambridge in the late 70s was that the CPL compiler required a silly number of passes and produced one error message: "sorry". Aside: CPL used qua as syntax for casting, which I've always thought to be rather cool. --JohnKozak
Reading the (first page of) the 1963 Barron et al paper I think it is more likely that the word "Combined" in the language name comes from the collaboration and I have changed the article to reflect that. The text from the paper is:
This paper provides an informal description of the main features of CPL, a programming language developed jointly by members of the University Mathematical Laboratory, Cambridge, and the University of London Computer Unit. (CPL is mnemonic for Combined Programming Language.) The object in developing CPL was to produce a language which could be used for all types of problem, numerical and non-numerical, and would allow programmers to exploit all the facilities of a large and powerful computer without having to "escape" into machine code.
What does anyone else think? --drj
Article currently reads:
...instead of being extremely small, elegant and simple, CPL was big, only moderately elegant, and complex. It was intended to be good for both scientific programming (in the way of FORTRAN and ALGOL) and also commercial programming (in the way of COBOL). In fact, it can be seen as a similar effort to PL/I in this way.
If you read "The main features of CPL", you'll see that in fact CPL is not all that complex -- no comparison at all to PL/I (I have removed that). I am not sure where the notion that it was intended for commercial programming came from: the article says it "could be used for all types of problem, numerical and non-numerical...without having to 'escape' into machine language"; that sounds more like they were interested in systems programming and string processing -- one doesn't typically escape into machine language for commercial programming. --macrakis (talk) 15:36, 10 January 2009 (UTC)
When at the Programming Research Group (1975-77) I was told that CPL was an abbreviation that started as "Christopher's Programming Language", and it was used mainly as a vehicle for theoretical discussion rather than intending it to be implemented. Christopher Strachey had an abiding interest and enormous influence upon the development of computer languages, especially in the area of precise semantic description. Zteve (talk) 18:48, 12 May 2009 (UTC)
Article currently reads: "CPL was a big language for its time. Some would compare it to ALGOL 68, PL/1, or Ada ... However, CPL proved overly complex for the memory restrained computers and immature compiler technologies of the time."
This is a strange statement in several ways. First of all, PL/1 (which must be bigger in many ways than CPL) was in fact implemented in the mid-60's; some compilers ran in as little as 64k (with multiple overlays). It is not clear what the point of comparing the 1963 CPL design to the 1983 Ada design is; even the 1983 Pascal design (Pascal being supposedly a simple language) was probably bigger than the CPL design. --macrakis (talk) 17:51, 15 May 2010 (UTC)
- Well, it may perhaps sound "strange", but I belive it's fairly true that CPL was complex for the immature compiler technologies of the time. That's why it took so long to implement. Complexity is not proportional to size, far from it. Also, Pascal was first introduced in 1969, not 1983. 220.127.116.11 (talk) 08:48, 1 August 2010 (UTC)
- So you are claiming that CPL was more complex than its contemporary, PL/I? CPL didn't even have records. The difference there is not so much in their size or complexity as the fact that PL/I had IBM behind it....
- As for Pascal, yes, the first version came out in 1969, and it was pretty simple -- partly because it was very incomplete; I was explicitly referring to the ISO Pascal of 1983.
- No, I did not mean to say it was more complex than PL/1, but just as PL/1 and ADA were initially hard to implement, so was CPL, as I understood it. I don't think records were the major complexity hog — they came from the fairly simple Cobol, and my experience is that they are relatively easy to implement. I belive recursive routines passed as arguments to recursive routines (what's called closures nowdays) and similar mechanisms was a bigger issue (this was not present in the simpler Fortran and Cobol). I agree there are little written information on CPL (more on BCPL though). Also, the original Pascal was not really very different from the 1983 standard. 18.104.22.168 (talk) 07:22, 2 August 2010 (UTC)
- I suspect (but don't have any good evidence) that the main problem in implementing CPL was that it was a university project with no sense of urgency, and probably insufficient resources. I wonder, too, if its design was well-defined and stable. Recursive routines passed as arguments to recursive routines (with lexical scope) had already been solved in Algol 60 (downwards funarg), if I'm not mistaken; however, I'm not sure about the status of 'upwards funargs' in either Algol 60 or CPL.
- About the original Pascal vs. ISO Pascal, in some sense the intent wasn't very different, but just look at the size of the specs: the original Pascal was 50 pages, ISO Pascal was hundreds. The original Pascal left undefined many important cases,Pascal (programming language)#cite_ref-5 like what happens when you access a variant record with the 'wrong' variant. It didn't have any way of specifying array size at runtime (which made it basically useless for any real application -- and added very considerable specification and implementation complexity). It didn't specify what it meant for two types to be equivalent (name equivalence vs. structural equivalence). (cf. Daniel M. Berry , Richard L. Schwartz, "Type equivalence in strongly typed languages: one more look", ACM SIGPLAN Notices 14:9 (September 1979)) --Macrakis (talk) 15:50, 2 August 2010 (UTC)
The sample program is given as:
Max(Items, ValueFunction) = value of § (Best, BestVal) = (NIL, -∞) while Items do § (Item, Val) = (Head(Items), ValueFunction(Head(Items))) if Val > BestVal then (Best, BestVal) := (Item, Val) Items := Rest(Items) § result is Best §
However, this is incorrect, as the closing bracket for a sequence of statements in CPL is not the section sign (§) but rather a section sign with a vertical stroke through it (which does not appear to be in Unicode).
For reference, see http://comjnl.oxfordjournals.org/content/6/2/134.full.pdf (in which you can just barely see evidence of the vertical stroke by looking at the pixels at the bottom of the symbol), and http://www.scientificamerican.com/article.cfm?id=system-analysis-and-programming-christopher-strachey (particularly in the example at the top of the second page).
How should this be corrected in the article? And is it true that there isn't a section-sign-with-vertical-stroke in Unicode? I find it hard to imagine Unicode overlooked any typographical symbol. DWorley (talk) 02:07, 23 May 2013 (UTC)
It looks like the section-sign-with-stroke can be composed in Unicode as "§⃒", which is § (U+00A7, SECTION SIGN) composed with ⃒ (U+20D2, COMBINING LONG VERTICAL LINE OVERLAY). It displays correctly in Emacs 23.3. This browser (Firefox 18.0.2 on Linux) displays it correctly in the text of this comment, but the characters do not compose in the code section shown below. Though in both cases, the visual distinction from the section sign is rather small.
Using it, the sample code becomes
Max(Items, ValueFunction) = value of § (Best, BestVal) = (NIL, -∞) while Items do § (Item, Val) = (Head(Items), ValueFunction(Head(Items))) if Val > BestVal then (Best, BestVal) := (Item, Val) Items := Rest(Items) §⃒ result is Best §⃒