Lambda the Ultimate - Programming Languages Weblog

Abstract interpreters for free

Sun, 29 Aug 2010 09:31:51 -0400

Matthew Might, "Abstract interpreters for free", Static Analysis Symposium 2010 (SAS 2010).

...we present a two-step method to convert a small-step concrete semantics into a family of sound, computable abstract interpretations. The first step re-factors the concrete state-space to eliminate recursive structure; this refactoring of the state-space simultaneously determines a store-passing-style transformation on the underlying concrete semantics. The second step uses inference rules to generate an abstract state-space and a Galois connection simultaneously. The Galois connection allows the calculation of the “optimal” abstract interpretation. The two-step process is unambiguous, but nondeterministic: at each step, analysis designers face choices. Some of these choices ultimately influence properties such as flow-, field- and context-sensitivity. Thus, under the method, we can give the emergence of these properties a graph-theoretic characterization.

The work in this paper provides some context for known static analysis techniques like k-CFA, and also opens up some interesting new directions for static analysis development. Also, as Matt points out, there are some pedagogical benefits to having a systematic process for getting from semantics to abstract interpretation.

Sapir-Whorf 70 years on

Sat, 28 Aug 2010 02:35:20 -0400

Many a people have looked at Programming Lanugages through the Sapir-Whorf lens so it's not uncommon to find people making PL claims using that hypothesis. Also not surprisingly, the topic keeps re-appearing here on LtU.

This week's NY Times magazine has an article titled Does Your Language Shape How You Think? by Guy Deutscher which starts as a retrospective on Whorf but then goes into what new research has shown.

Some 50 years ago, the renowned linguist Roman Jakobson pointed out a crucial fact about differences between languages in a pithy maxim: “Languages differ essentially in what they must convey and not in what they may convey.” This maxim offers us the key to unlocking the real force of the mother tongue: if different languages influence our minds in different ways, this is not because of what our language allows us to think but rather because of what it habitually obliges us to think about.

...

When your language routinely obliges you to specify certain types of information, it forces you to be attentive to certain details in the world and to certain aspects of experience that speakers of other languages may not be required to think about all the time. And since such habits of speech are cultivated from the earliest age, it is only natural that they can settle into habits of mind that go beyond language itself, affecting your experiences, perceptions, associations, feelings, memories and orientation in the world.

Ocaml 3.12 released

Tue, 17 Aug 2010 06:22:46 -0400

This notice comes a little late, but the latest version of OCaml, version 3.12, has been released. Surprisingly, for a point release there's a lot of interesting new language features:

Some of the highlights in release 3.12 are:

Polymorphic recursion is supported, using explicit type declarations on the recursively-defined identifiers.
First-class modules: module expressions can be embedded as values of the core language, then manipulated like any other first-class value, then projected back to the module level.
New operator to modify a signature a posteriori: S with type t := tau denotes signature S where the t type component is removed and substituted by the type tau elsewhere.
New notations for record expressions and record patterns: { lbl } as shorthand for { lbl = lbl }, and { ...; _ } marks record patterns where some labels were intentionally omitted.
Local open let open ... in ... now supported by popular demand.
Type variables can be bound as type parameters to functions; such types are treated like abstract types within the function body, and like type variables (possibly generalized) outside.
The module type of construct enables to recover the module type of a given module.
Explicit method override using the method! keyword, with associated warnings and errors.

I'm especially intrigued by first-class modules, and the destructive signature operations, both of which should make it much easier to write libraries.

Type Classes as Objects and Implicits

Wed, 04 Aug 2010 18:25:48 -0400

Type Classes as Objects and Implicits

Type classes were originally developed in Haskell as a disciplined alternative to ad-hoc polymorphism. Type classes have been shown to provide a type-safe solution to important challenges in software engineering and programming languages such as, for example, retroactive extension of programs. They are also recognized as a good mechanism for concept-based generic programming and, more recently, have evolved into a mechanism for type-level computation. This paper presents a lightweight approach to type classes in object-oriented (OO) languages with generics using the CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).

This paper also shows how Scala’s type system conspires with implicits to enable, and even surpass, many common extensions of the Haskell type class system, making Scala ideally suited for generic programming in the large.

Martin Odersky and team's design decisions around how to do type classes in a unified OO and FP language continue to bear fascinating fruit. Implicits look less and less like "poor man's type classes," and more and more like an improvement upon type classes, in my opinion given a quick read of this paper.

What Sequential Games, the Tychonoff Theorem and the Double-Negation Shift have in Common

Wed, 04 Aug 2010 06:12:04 -0400

What Sequential Games, the Tychonoff Theorem, and the Double-Negation Shift have in Common, Martin Escardo and Paulo Oliva, to appear in MSFP 2010.

This is a tutorial for mathematically inclined functional programmers, based on previously published, peered reviewed theoretical work. We discuss a higher-type functional, written here in the functional programming language Haskell, which

optimally plays sequential games,
implements a computational version of the Tychonoff Theorem from topology, and
realizes the Double-Negation Shift from logic and proof theory.

The functional makes sense for finite and infinite (lazy) lists, and in the binary case it amounts to an operation that is available in any (strong) monad.

In fact, once we define this monad in Haskell, it turns out that this amazingly versatile functional is already available in Haskell, in the standard prelude, called sequence, which iterates this binary operation. Therefore Haskell proves that this functional is even more versatile than anticipated, as the function sequence was introduced for other purposes by the language designers, in particular the iteration of a list of monadic effects (but effects are not what we discuss here).

One of the most durable and productive analogies in semantics is the analogy between computability and continuity. Depending on how you read the history, this idea might even predate computers: Brouwer proved that all intuitonistic functions on the reals were continuous.

Over the last few years, Escardo and his collaborators have done a lot of cool stuff showing how this network of ideas can be turned into miraculous-looking little programs, so it's very nice to see a relatively accesible introduction to this work.

It's been ten years!

Wed, 28 Jul 2010 01:26:56 -0400

It has been ten years since LtU was launched. When I launched it I had no idea if anyone will read the site, let alone if people contribute new stories. The result exceeded my wildest hopes.

I got into the habit of writing a few words every year, a kind of "state of lambda" post. Somehow, this feels inappropriate for the ten year anniversary. I will possibly post something about last year later this week, but let's take a moment to celebrate our first ten years.

There are a lot of things that can be said, and a few things that perhaps should be said. I personally will say little. The thread is open.

For my part, I just want to thank all those how contributed to LtU over the years, whether by submitting new stories, by participating in the discussion, or with help with administrative and hosting issues. Some, of course, helped with any and all tasks.

It is great to see that some members that have been with LtU from its early years are still here. Some members that left have come back, and those that decided to move on to other things are still part of the ethos of LtU, as well as the archives, as we move towards the future.

The Mirah Language

Fri, 23 Jul 2010 07:16:07 -0400

Mirah is a new language from Charles Nutter, the developer of JRuby. He describes it thus:

Mirah is ... a repurposing of Ruby’s syntax to a flexible toolchain suitable for compiling to any number of type systems and runtimes with maximum performance.

Mirah’s design is centered around a few simple principals:

Platform-agnostic

Free from concrete decisions about the back-end type system

Code generation, or other details are specified by the outward language

I think Mirah is a bit too new to make a front-page post. It is interesting and also puzzling in that it doesn't really define a semantics. E.g. “roughly similar scripts could conceivably compile to any number of type systems and runtimes. In this sense, Mirah is more of a rough coupling of Ruby-like syntax with a pluggable type-inference and compilation pipeline.” Can you actually claim you've created a language if the semantics of the language aren't specified? I'm not sure whether to file this under interesting or quackers.

Scribble: Closing the Book on Ad Hoc Documentation Tools

Tue, 20 Jul 2010 21:18:45 -0400

Scribble: Closing the Book on Ad Hoc Documentation Tools. Matthew Flatt, Eli Barzilay, and Robert Bruce Findler. ICFP '09.

Scribble is a new system for writing library documentation, user guides, and tutorials. Scribble builds on PLT Scheme’s technology for language extension, and at its heart is a new approach to connecting prose references with library bindings. We have built Scribble libraries that support standalone documentation and papers, JavaDoc-style API documentation, and literate programming. Thanks in large part to Scribble’s flexibility and the ease with which we can cross-reference information across different levels, the documentation that is distributed with PLT Scheme now runs into the thousands of pages. This paper reports on the use of Scribble and on its design as both an extension and extensible part of PLT Scheme.

This introduces a cute and well thought out syntax for writing technical prose and for escaping back into the PL for typesetting operations and cross-references to PL values. It looks reminiscent of TeX, but has a direct transformation to S-expressions. Scribble also makes great use of PLT Scheme's modular and polyglot programming facilities.

A nice twist on the classic Scheme ploy:

A documentation language should be designed not by piling escape conventions on top of a comment syntax, but by removing the weaknesses and restrictions of the programming language that make a separate documentation language appear necessary. Scribble demonstrates that a small number of rules for forming documentation, with no restrictions on how they are composed, suffice to form a practical and efficient documentation language that is flexible enough to support the major documentation paradigms in use today.

(P.S. To which I'd like to add, somewhat OT, that compared to PLT Scheme, Common Lisp is starting to look teeny.)

The Future of C#

Mon, 19 Jul 2010 20:54:51 -0400

One of the future additions to C# announced by Anders Hejlsberg in this entertaining video from 2008 is Compiler as a Service. By that he means the ability to eval code strings (and I'm guessing that this will also be integrated with C#'s built-in AST objects).

He shows this off at around minute 59, to great effect and great excitement by the audience. It feels like an inflection point. There probably won't be another REPL-less language from now on.

I predict that after that, they'll add hygienic macros and quasisyntax.

App Inventor: Programming for non-programmers... again

Mon, 12 Jul 2010 15:50:18 -0400

From the App Inventor about page:

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app's behavior.

It seems we've been here before. (and I don't just mean that it's based on Open Blocks and Kawa)

The Rust Language

Thu, 08 Jul 2010 09:37:44 -0400

Rust is systems programming languages being developed by Mozilla. It's very preliminary work, but the list of features suggests an interesting intersection of features. I'm particularly excited by the control over memory layout that Rust gives to the programmer, but it also has massive concurrency, structural typing, and the “ability to define complex invariants that hold over data structures” in its bag of tricks.

The main developer is Graydon Hoare, with contributions from heroes-to-the-Internet Dave Herman and Brendan Eich amongst others.

Handlers of Algebraic Effects

Sun, 04 Jul 2010 05:54:45 -0400

Matija Pretnar, Gordon Plotkin (2009) Handlers of Algebraic Effects:

We present an algebraic treatment of exception handlers and,
more generally, introduce handlers for other computational effects repre-
sentable by an algebraic theory. These include nondeterminism, interac-
tive input/output, concurrency, state, time, and their combinations; in
all cases the computation monad is the free-model monad of the theory.
Each such handler corresponds to a model of the theory for the effects
at hand. The handling construct, which applies a handler to a compu-
tation, is based on the one introduced by Benton and Kennedy, and is
interpreted using the homomorphism induced by the universal property
of the free model. This general construct can be used to describe previ-
ously unrelated concepts from both theory and practice.

Handling a computational effect, such as raising an exception, amounts to homomorphically mapping the handled computation onto another computation. So, for example, raise is interpreted as the exception handling code given to the handler.

While encompassing both returning and non-returning handlers, this idea becomes more interesting when you start to handle the other effects, such as lookup and update. Then you can get things like state rollback when an exception occurs, and others (CSS renaming and hiding, stream redirection, timeout). Thus the semantics of handlers gives rise to a new programming construct.

If you want a gentler introduction to the subject (along with Plotkin's algebraic theory of effects and Levy's Call-by-Push-Value), try Pretnar's 2010 thesis.

Traceable Data Types for Self-Adjusting Computation

Sat, 03 Jul 2010 19:35:31 -0400

This post is triggered by Jules asking, essentially, how could FRP support imperative structures? Part of the answer is about interface -- a command becomes an input stream of commands, which is a common pattern in systems like Max/MSP, and most FRP systems also provide mutable reactive cells (... a worthwhile topic for another day). More interesting is when we want a particular imperative implementation that the automatic incrementalizer wouldn't have picked, such as a hand-tuned one in a lower-level language. Sometimes, a reactive language supports interfacing with alternative implementations in other languages automatically, as in Crossing State Lines: Adopting OO Frameworks to Functional Reactive Languages, but, as long as the incrementalization algorithm supports foreign computations, even language users can do it (e.g., Flapjax supports manual lifting of the DOM, I also did arrays, etc.).

The following recent paper, Traceable Data Types for Self-Adjusting Computation, can be interpreted as an explanation of why it has been sensible performance-wise for an FRP system like Flapjax to lift a library like the DOM: in a typed setting, the library is an ADT that has been tuned to take care of its own incrementalization and thus we just need a bit of glue to lift it:

In this paper, we extend dependence-tracing to work at the granularity of the query and update operations of arbitrary (abstract) data types, instead of just reads and writes on memory cells. This can significantly reduce the number of dependencies that need to be kept in the trace and followed during an update. We define an interface for supporting a traceable version of a data type, which reports the earliest query that depends on (is changed by) revising operations back in time, and implement several such structures, including priority queues, queues, dictionaries, and counters. We develop a semantics for tracing, extend an existing self-adjusting language, ∆ML, and its implementation to support traceable data types, and present an experimental evaluation by considering a number of benchmarks. Our experiments show dramatic improvements on space and time, sometimes by as much as two orders of magnitude.

A little more out there, and why I liked this paper, is its typed phrasing allows you to reduce the typical lifting+FFI approach for automatic incrementalization of general programs to being an instance of the the expression problem.

An intuitionistic logic that proves Markov's principle

Fri, 02 Jul 2010 05:36:04 -0400

“An intuitionistic logic that proves Markov's principle”, Hugo Herbelin, LICS 2010.

We design an intuitionistic predicate logic that supports a limited amount of classical reasoning, just enough to prove a variant of Markov’s principle suited for predicate logic.

At the computational level, the extraction of an existential witness out of a proof of its double negation is done by using a form of statically-bound exception mechanism, what can be seen as a direct-style variant of Friedman’s A-translation.

Markov's principle is an axiom of "Russian constructivism". It says that if P is a decidable predicate (i.e., the formula ∀x. P(x) or ¬P(x) is constructively provable), then if we know that P is not always false (ie ¬(∀x. ¬P(x))), then there exists an x such that P holds (ie ∃x. P(x)).

One operational way of understanding this axiom is that it says is that if we know P is not always false (on, say, the natural numbers), we can find an element for which it is true with a while-loop: check to see if 1 is true, and then check to see if 2 is true, and so on, stopping when you hit a number for which it holds. This means that Markov's principle is a principle of unbounded search, and as a result it has controversial status in intuitionistic mathematics -- should we regard a program with a non-constructive termination proof as a constructively terminating program? (The answer is, as usual, "it depends": in different applications you can want it or not.)

However, just chucking an axiom like ¬(∀x. ¬P(x)) → ∃x. P(x) into your proof rules is not very nice from a proof-theoretic perspective. It mixes up a bunch of different logical connectives, and adding it as an axiom will break things like the cut-elimination theorem for sequent calculus.

In this paper, Herbelin exploits (a) the fact that Markov's principle is a (mildly) classical principle of reasoning, and (b) the fact that classical logic is connected with control operators like continuations, to give a logic which is proof-theoretically well-behaved, but which supports Markov's principle. The trick is to add first-class continuations, but only for value types (ie, you can throw products and sums, but not functions).

What I find surprising is that this same class of restriction also arises in another paper on control operators at LICS -- Noam Zeilberger's paper "Polarity and the Logic of Delimited Continuations" uses it too. (This paper deserves a post here too.)

Compiling Structural Types on the JVM

Wed, 30 Jun 2010 11:18:49 -0400

Here's a little sausage making article for JVM language implementors. In Compiling Structural Types on the JVM: A Comparison of Reflective and Generative Techniques from Scala’s Perspective, Gilles Dubochet and Martin Odersky describe

Scala’s compilation technique of structural types for the JVM. The technique uses Java reflection and polymorphic inline caches. Performance measurements of this technique are presented and analysed. Further measurements compare Scala’s reflective technique with the “generative” technique used by Whiteoak to compile structural types. The article ends with a comparison of reflective and generative techniques for compiling structural types. It concludes that generative techniques may, in specific cases, exhibit higher performances than reflective approaches, but that reflective techniques are easier to implement and have fewer restrictions.

There's no discussion of the the proposed JVM "method handles" and whether they might be an even better solution than runtime reflection.

Whiteoak was mentioned previously on LtU.