Lambda the Ultimate

From: mike@erix.ericsson.se (Mike Williams)
To: erlang-questions@erlang.org

[...]

As one of the main "actors" in "Erlang the Movie", I
absolutely and categorically forbid its showing *anywhere*. If there
was a competition for "turkey" short movies, I think we would win
hands down.

So, please, please, please, forget we made that retched film in 1990!

That's right, now you too can own the movie that "Bjarne used whenever he wanted to get rid of unwanted guests at CS lab parties"! Download the torrent or the file on erlang.org if you have 200MB of disk space to spare!

No, no and again, NO!!!

You're part of the C# language design team thinking about the next version of C# (ie the version after VS 2005). You get the following email:

When I'm writing code, I often come across a situation where my code throws an exception because another component called with a null parameter. I'd like a way to prevent that from happening.

What are the pros and cons of such a feature? What are the ramifications of adding it to the language? What would have to change? What is your recommendation? Exactly what would such a feature look like?

A discussion over on Eric Gunnerson's weblog.

I suppose this is one way of doing language design. You are welcome to comment on the specific issue, or on this cutting edge language design technique ("just blog it, silly")...

Just to get the juices flowing, I should point out that this is a type system issue.

Should we have a language design department for general discussions about language design?

Here's something to offset all the
long discussions on typing that
have been taking place recently
(see Concurrent Components With Message Passing):

In our experience, the right default for structuring programs is as concurrent components that communicate through asynchronous message passing. Components should be sequential or communicate synchronously only if necessary. This is not a new idea; Carl Hewitt anticipated it thirty years ago in the Actor model. But today we have many strong reasons for accepting it. For example: [...] (discussion continues with
references to Erlang, E, and CTM)
[...] Unfortunately, these reasons and their conclusion are almost completely ignored by mainstream languages and by books on program design. In both, object-oriented programming and shared-state concurrency are given priority, even though they are the wrong default. [...]

So, is this heresy or an unfortunately ignored truth?

A short and accessible explanation of decorators (new in Pyton 2.4). [via Keith]

We extend the "scrap your boilerplate" style of generic programming in Haskell to accomplish an additional range of applications. This includes several forms of serialisation and de-serialisation, test-set generation, type validation, and type erasure. To this end, we provide a well-designed reflection API for datatypes and constructors, and we also provide more general means of extending generic functions for given monomorphic or polymorphic types. The presented approach is readily supported in the GHC implementation of Haskell.

The previous "boilerplate" paper was discussed here in the past.

This is a interesting paper and there are many reasons why I should link to it, but I'll let you guess the number 1 reason (hint: check section 10).

Kendall Clark of the Data Access Working Group (part of the W3C's Semantic Web initiative) has posted regarding their work on a query language and access protocol for RDF. The DAWG has recently released the 2nd draft of its Use Cases and Requirements and is looking for community input. Their initial query language design, BRQL, looks SQL-like but is designed to operate on graphs/sets of triples.

Abstract: The Self system attempts to integrate intellectual and non-intellectual aspects of programming to create an overall experience. The language semantics, user interface, and implementation each help create this integrated experience. The language semantics embed the programmer in a uniform world of simple objects that can be modified without appealing to definitions of abstractions. In a similar way, the graphical interface puts the user into a uniform world of tangible objects that can be directly manipulated and changed without switching modes. The implementation strives to support the world-of-objects illusion by minimizing perceptible pauses and by providing true source-level semantics without sac rificing performance. As a side benefit, it encourages factoring. Although we see areas that fall short of the vision, on the whole, the language, interface, and im plementation conspire so that the Self programmer lives and acts in a consistent and malleable world of objects.

Featured in Sun Labs: The First Ten Years (1991-2001).

Unfortunately their website appears as a black hole if you have TCP Explicit Congestion Notification enabled. This is the default with Linux 2.6, but you can disable it with:

echo 0 > /proc/sys/net/ipv4/tcp_ecn

The scripting in MzTake is done in the FrTime language. This connection is based on the observation that the program being monitored is a source of events, and FrTime is designed well to receive events from the outside world. Therefore, the script programmer has the full power of FrTime (which includes almost all of Scheme, graphical routines and some rudimentary GUI support, in addition to several event-based programming primitives) for automating program monitoring.

The site includes several examples that are worth checking even if you aren't planning on installing MzTake.

I like the idea of program monitoring. It is related to the notion of instrumentation, which is of course a well known sofware design technique.

This is yet another example of how language design can help handle software engineering issues.

We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.

Jon Udell is one of the champions of so-called dynamic languages. This item is yet another attempt to explain the importance of dynamic languages and the central role they should play in building complex networked applications.

I am sure all you guys debating static typing in the forum are going to find this worth reading (and worth debating).

First-class labels for extensible rows. (draft)
Daan Leijen.
Submitted to POPL'05. (PDF, BibTeX)

Abstract: This paper describes a type system for extensible records and variants with first-class labels; labels are polymorphic and can be passed as arguments. This increases the expressiveness of conventional record calculi significantly, and we show how we can encode intersection types, closed-world overloading, type case, label selective calculi, and first-class messages. We formally motivate the need for row equality predicates to express type constraints in the presence of polymorphic labels. This naturally leads to an orthogonal treatment of unrestricted row polymorphism that can be used to express first-class patterns. Based on the theory of qualified types, we present an effective type inference algorithm and efficient compilation method. The type inference algorithm, including the discussed extensions, is fully implemented in the experimental Morrow compiler.

Always trust Daan to come up with something both elegant and practical...! However the examples involving bottom (undefined) labels left me skeptical.