Lambda the Ultimate

The Pirahã were discussed here a couple of times, in the context of the linguistic relativity hypothesis (Sapir-Whorf). One of the controversial claims about the Pirahã language was that it lacked recursion (which is found in all human languages, and is seen as an essential feature of human language).

This paper by Andrew Ira Nevins, David Pesetsky, and Cilene Rodrigues attempts to refute many of the fantastic claims about Pirahã, and includes a detailed argument against the claims about the lack of syntactic recursion and embedding (to get to the full text, click on the title at the top of the page).

Java was actually designed to have tuples from the start, but they never quite got in. At one point, I tried to add a tuple-like construct as part of JSR-65. We wanted to extend array initializers to full blown expressions. Eventually, that effort got quashed; I didn’t really resist, since the extension was painful, as such things always are in Java. We should have just done straight tuples as a separate construct - but at the time, that was frowned upon too.

Not surprisingly, Gilad thinks that tuples are great.

In contrast to his earlier attempts, which I appreciated, this time Felten does not try to prove his point by explaining the fundamental facts of computer science. Understading programs is hard, he demonstrates here, because the results of some mathematical functions are hard to predict (in his example, a secure hash function).

While this enables Felten to give a short and easy to understand example, I think he misses the chance to explain why understanding (and predicting) program behaviour is hard in general. This would bring him back to the fundamental principles he discussed before, stemming from the halting problem. By going this route it would be possible to relate the issue under discussion to topics that are more directly related to LtU: how programming languages can help make analyzing program behaviour easier, how languages can restrict possible behaviours etc.

Be that as it may, more people outside the profession should be come to appreciate that understanding program behaviour is hard. This is something that takes time to appreciate fully, even when you are a programmer. It is one thing to know that finding bugs is hard in practice and quite another to appreciate the reasons why it is inherently so.

Google video recording of Alan Kay's OOPSLA 1997 keynote. Very good!

Shape analysis for composite data structures. MSR-TR-2007-13.

We propose a shape analysis that adapts to some of the complex composite data structures found in industrial systems-level programs. Examples of such data structures include ``cyclic doubly-linked lists of acyclic doubly-linked lists'', ``singly-linked lists of cyclic doubly-linked lists with back-pointers to head nodes'', etc. The analysis introduces the use of generic higher-order inductive predicates describing spatial relationships together with a method of synthesizing new parametrized spatial predicates which can be used in combination with the higher-order predicates. In order to evaluate the proposed approach for realistic programs we have implemented the analysis and performed experiments with it on examples drawn from device drivers. During our experiments the analysis proved the memory safety of several routines belonging to an IEEE 1394 (firewire) driver, and also found several previously unknown memory safety bugs and memory leaks. To our knowledge this represents the first known successful application of shape analysis to non-trivial systems-level code.

Seems relevant to some of the discussions currently going on (e.g., how PLT can help practitioners).

The analysis described in this paper fits in to the common structure of shape analyses, and is based on abstract interpretation.

We propose programming language mechanisms to reduce redundancy in program source code. These abbreviation mechanisms, shorthands, make programs shorter and easier to write and read. In addition, we provide a framework for describing language abbreviation mechanisms.

An interesting and odd paper from Todd Proebsting (of "Proebsting's Law"fame) and Ben Zorn. If you like $_ and @_ in Perl, then you may like this, too. I can't recall seeing any other papers on this topic, so pointers are welcome.

I am sad to note that Jean Ichbiah, the lead designer of Ada, passed away on January 26, 2007.

Ada83, the reference manual for which appeared in 1983, is commonly known as the first version of Ada. Prior to that, in 1977, four contractors were picked to produce prototype languages, matching the requirements of the Ironman document (which led the way to the final Ada requirements specification, the Steelman). The prototypes were named green, red, blue and yellow. The green language, proposed by a team at Cii Honeywell Bull led by Jean D. Ichbiah, was chosen and led the way to Ada83. See here for more detailed timeline of the history of Ada.

While the design of Ada83 and Ada95 were both team efforts, in both cases the design was guided by a team leader whose vision and aesthetics regarding programming languages shaped the language. All versions of Ada owe much to Jean Ichbiah who shaped the core of the language used today.

Extremely attractive overview and slides about a one-hour Erlang talk by André Pang at linux.conf.au 2007.

I gave a talk titled Concurrency and Erlang at Linux.conf.au in January, 2007. Thank you so much to everybody who attended it and made me feel welcome: I got overwhelmingly positive feedback from it, and it was an honour to speak at such an esteemed conference.

Another reason I wish I'd talked myself into attending this conference!

The second draft of R6RS, version 5.92, is now available at www.r6rs.org. (For more general information about Scheme standards, see the Standards page at schemers.org.)

This version of R6RS incorporates the responses to the formal comments that were submitted prior to Nov 15th, 2006. A few of the changes are highlighted below (not intended to be comprehensive):

• The report has been split into two separate documents: one for the base language, and one for the standard libraries. (A third document is currently planned, to include certain non-normative appendices.)
• The I/O system has been significantly revised.
• A number of features have been dropped from the report, including the inexact arithmetic library and the declarations feature.
• The report now includes a formal operational semantics, developed by Robby Findler and Jacob Matthews, building on their semantics for R5RS.
• "Top-level programs" replace scripts in the base language, eliminating certain OS-specificities, with a specification for scripts to be added in a non-normative appendix.

The current six-month public comment period is still ongoing, and will continue until March 15, 2007. The schedule subsequent to that date can be found here.

The editors encourage comments on the report, either informally on the discuss@r6rs.org mailing list, or via the formal comment process.

Of course, kibitzing here on LtU is welcome too! (Previous discussions on LtU include the announcement of the previous draft and the June status report.)

We'd like to announce availability of a preliminary, open source, interpreter implementing a small core of the Fortress programming language. This interpreter runs on the JVM. You can download the source code at: http://fortress.sunsource.net/.

Our intention is to grow this implementation over time, with the help of university partners and other interested third parties. We expect that many parts of this interpreter will be used as components of a complete Fortress compiler, which is our long term goal.

Fortress has been discussed here several times.

(Posted by Sukyoung Ryu to the TYPES forum.)