Lambda the Ultimate

According to a draft statement, Scheme is to be split into a small and a large language, the small being designed for educators and "50-page purists", the large for "programmers, implementors".

The small language should remain true to the language design precepts found in the RnRS introduction ("Programming languages should be designed not by piling feature on top of feature, …").

But what about the large one? Will it drop continuations, become a Lisp-2, and challenge Common Lisp?

Certified Web Services in Ynot

In this paper we demonstrate that it is possible to implement certified web systems in a way not much different from writing Standard ML or Haskell code, including use of imperative features like pointers, files, and socket I/O. We present a web-based course gradebook application developed with Ynot, a Coq library for certified imperative programming. We add a dialog-based I/O system to Ynot, and we extend Ynot’s underlying Hoare logic with event traces to reason about I/O behavior. Expressive abstractions allow the modular certification of both high level specifications like privacy guarantees and low level properties like memory safety and correct parsing.

Ynot, always ambitious, takes another serious swing: extracting a real web application from a proof development. In some respects the big news here is the additional coverage that Ynot now offers in terms of support for file and socket I/O, and the event trace mechanism. But there's even bigger news, IMHO, which is the subject of another paper that warrants a separate post.

The Simple programming language is a BASIC dialect for the Android platform highly influenced by Microsofts's pre-dot-NET Visual Basic.

In the 90s, a big company from up north was extremely successful with a dialect of the programming language BASIC (acronym for Beginner's All-purpose Symbolic Instruction Code). One of the reasons it was so successful was that the language was easy to learn and use.

Bringing an easy to learn and use language to the mobile world and the Android platform is the goal of the Simple project. Simple is a BASIC dialect for developing Android applications. It is particularly well suited for non-professional programmers (but not limited to). Simple allows programmers to quickly write Android applications by using the components supplied by its runtime system.

Similar to its 90s relative, Simple programs are form definitions (which contain components) and code (which contains the program logic). The interaction between the components and the program logic happens through events triggered by the components. The program logic consists of event handlers which contain code reacting to the events.

Energy-efficient computing is important in several systems ranging from embedded devices to large scale data centers. Several application domains offer the opportunity to tradeoff quality of service/solution (QoS) for improvements in performance and reduction in energy consumption. Programmers sometimes take advantage of such opportunities, albeit in an ad-hoc manner and often without providing any QoS guarantees. We propose a system called Green that provides a simple and flexible framework that allows programmers to take advantage of such approximation opportunities in a systematic manner while providing statistical QoS guarantees. Green enables programmers to approximate expensive functions and loops and operates in two phases. In the calibration phase, it builds a model of the QoS loss produced by the approximation. This model is used in the operational phase to make approximation decisions based on the QoS constraints specified by the programmer. The operational phase also includes an adaptation function that occasionally monitors the runtime behavior and changes the approximation decisions and QoS model to provide strong QoS guarantees.

The basic approach is not specific to energy considerations, and is basically based on placing approximation code based on profiling data. Energy is measured by sampling current and voltage from the main power cable.

It is nice to see programming language ideas being put to use to help protect the environment...

The system was implemented using the Phoenix compiler framework.

Found via Wadler's blog: PLATEAU is calling for papers on the HCI side of PL theory, design, and tooling.

Programming languages exist to enable programmers to develop software effectively. But how efficiently programmers can write software depends on the usability of the languages and tools that they develop with. The aim of this workshop is to discuss methods, metrics and techniques for evaluating the usability of languages and language tools. The supposed benefits of such languages and tools cover a large space, including making programs easier to read, write, and maintain; allowing programmers to write more flexible and powerful programs; and restricting programs to make them more safe and secure.

On Monday, July 13th the C++ standards committee voted "Concepts" out of consideration for C++0x.

First, skepticism regarding the feasibility and usefulness of concepts intensified the antipathy towards this proposal. Some people expressed concerns about compile-time and runtime overhead. Second, the creators of the Concepts proposal tried desperately to improve and patch Concepts. The last nail in the coffin was Bjarne Stroustrup's paper "Simplifying the Use of Concepts" from June. It's a masterpiece in terms of presenting Concepts but it also scared folks. The general sense was that concepts were broken, the committee was not sure what the correct direction was to fix them, and it would probably take several more years to come up with a reasonable fix that would achieve consensus. Considering that Concepts were originally designed to simplify C++, a critical mass of committee members agreed in July 2009 that it was time to bid Concepts goodbye.

Edit:

For more on the meeting see "The View (or trip report) from the July 2009 C++ Standard Meeting" part 1 and part 2

Edit 2:

Bjarne Stroustrup on The C++0x "Remove Concepts" Decision.

the RepRap is a self-replicating machine (3D printer) created by Adrian Bowyer.

Look at your computer setup and imagine that you hooked up a 3D printer. Instead of printing on bits of paper this 3D printer makes real, robust, mechanical parts. To give you an idea of how robust, think Lego bricks and you're in the right area. You could make lots of useful stuff, but interestingly you could also make most of the parts to make another 3D printer. That would be a machine that could copy itself.

There are RepRap machines around the world these days. LtU readers are invited to report their experiences!

a recent opencores.com article by Jeremy Bennett.

Open source is well established as a business model in the software world. Red Hat is now approaching the market capitalization of Sun Microsystems, while IBM, the worlds largest patent holder, makes more money from open source than other software (source: BBC Radio 4 “In Business”). Major tools such as the Firefox web browser, the Apache web server and the Eclipse IDE are all open source.

...

Now here's a novel idea. What about open source for hardware? At first sight this seems a non-starter. Open source relies on the nil marginal cost of software distribution, but hardware has to be manufactured.

But a modern silicon chip is typically built from silicon “intellectual property” (IP), written in a hardware description language such as Verilog or VHDL. Fabless design houses may never produce a chip themselves—one of the largest and best known is ARM in Cambridge, whose processor IP is built by other companies into one billion chips ever month. That IP costs the same amount to produce, whether it goes into one chip or one billion.

Hardware is software, and open-source hardware looks like a red-hot area these days. Do we have any open-source hardware developers lurking on LtU? If so please say hello. :-)

Reaction-time and eye-fixation data are analyzed to investigate how people infer the kinematics of simple mechanical systems (pulley systems) from diagrams showing their static configuration. It is proposed that this mental animation process involves decomposing the representation of a pulley system into smaller units corresponding to the machine components and animating these components in a sequence corresponding to the causal sequence of events in the machine's operation. Although it is possible for people to make inferences against the chain of causality in the machine, these inferences are more difficult, and people have a preference for inferences in the direction of causality. The mental animation process reflects both capacity limitations and limitations of mechanical knowledge.

Following the theme of yesterday's post this is another non-PL research paper that explores cognitive factors that might be relevant to programming language design.

The research in the paper nicely illustrates how different accounts of the cognitive processes involved in reasoning about the behavior of a mechanical system or model can be compared experimentally. The results suggest the types of inferences that are involved in mental animation of the type requested from the subjects, and how they are orchestrated.

The first section of the paper provides the general framework, and explains the notion of mental animation. A discussion of the generality of the results can be found at the end of the paper.

Those who find my last two posts too far removed from PL issues need not worry; I am not going to post more research of this type soon. Those who are intrigued by this research will be happy to know that a lot more is available where this came from.

The advantages of diagrams, in our view, are computational. That is diagrams can be better representations not because they contain more information, but because the indexing of this information can support extremely useful and efficient computational processes. But this means that diagrams are useful only to those who know the appropriate computational processes for taking advantage of them. Furthermore, a problem solver often also needs the knowledge of how to construct a "good" diagram that lets him take advantage of the virtues we have discussed. In short, the ideas we have presented, not only provide an explanation of why diagrams can be so useful, but also provide a framework for further study of the knowledge required for effective diagram use.

While this paper is not about programming languages, it describes research that may be relevant to the discussion of visual programming languages versus textual languages as well as other language design decisions. Seeing as human factors were recently mentioned, and that it seems to be cognitive-week here on LtU, I thought this paper might be of interest.

While I am sure this paper can be discussed from many angles, I'll only mention two. 1. While this paper is old, I still find it remarkable how old fashioned it seems. I am not sure exactly what causes it to feel this way; probably something in the writing style. 2. While I haven't searched the literature, I don't recall seeing research on programming languages that uses the framework suggested by this paper even though Simon's work was, of course, well known to computer scientists in general, and PL researchers in particular.