Tag: Language

Most programming languages are created without any theory

The argument is made in this quote that most programming languages are created without any theory, and end up looking for it later, and rarely find it.

Here is the quote from Robin Milner:

Is there any lesson from the research field that you don’t see applied?

Robin: Most programming languages have been desgined without first thinking about the theory on which the meaning would be based. So, very often a language gets designed and implemented, and then what it means, what is supposed to happen when every program is run, is not necessarily predicted. Of course it was in some cases wonderfuly predicted, for example, in ALGOL60; the ALGOL60 report of 1960 was so accurate that one could follow it and find out what was going to happen. This isn’t always the case. Even in the good languages, the formal basis is not there before the language arrives, so what people do is later to retrofit a theory of meaning to the language, and maybe that means that the design could not take advantage of theoretical understanding.

Why Scheme has tail call optimization

Actors was Hewitt’s attempt to model Smalltalk. Scheme was Steele and Sussman’s attempt to understand Actors. TCO was inherited from Actors. It is an OOP concept.

I confirmed this with Guy when I prepared for my ECOOP talk and I have the relevant email somewhere.

– Matthias

(via PLT [1])

[1]: “guido on tail recursion” Dimitris Vyzovitis vyzo at media.mit.edu Thu Apr 23 00:01:01 EDT 2009

Decentralized Scheme Code Tracker

Aaron posted here here about Descot; a scheme to manage Scheme libraries. This is the alpha version. Based on his explanation, my impression is that the goal is to simplify the management and distribution of libraries without being a package manager itself like PLT and Chicken Scheme include. Those managers, though, might use Descot as a source of libraries.

Two sids of the same coin: coroutines and streams

Jos asked here:

It seems to me that in many cases the same problem can be solved (for an eager evaluater) both by coroutines and by streams. Both solutions very well show the structure of the principal algorithm as might have been written with a lazy evaluator in mind. Which approach would be preferred in terms of efficiency (time and memory). May be you would like to address other aspects as well. One reason that makes me tend to choose streams, is that the latter seem better suited to automatic code generation from purely lazy code.

To which Matthais replied here:

It is indeed a well-known fact that streams and coroutines are two sides of the same coin. Talcott’s 1986 dissertation is the earliest theoretical treatment that I know.

Which Jim clarified here:

I believe the reference is to Carolyn Talcott’s dissertation “The essence of Rum: A theory of intensional and extensional aspects of Lisp-type computation”. Stanford, 1986. Unfortunately this is not available online, as far as I know.

TSPL 4th edition

The 4th edition of The Scheme Programming Language by R. Kent Dybvig is announced in the MIT Press catalog.

“The fourth edition has been substantially revised and expanded to bring the content up to date with the current Scheme standard, the Revised6 Report on Scheme. All parts of the book were updated and three new chapters were added, covering the language’s new library, exception handling, and record-definition features.”

The paper catalog gives a date of July 2009. The online catalog gives a date of September 2009.

http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=11984

(via comp.lang.scheme)