Lambda the Ultimate

Chickenfoot is a tool that puts a programming environment in Firefox so you can write scripts to manipulate web pages and automate web browsing. In Chickenfoot, scripts are written in a superset of Javascript that includes special functions specific to web tasks.

Chickenfoot is similar to Greasemonkey, but tries to provide a higher level abstraction of web pages, more appropriate for end-user programming.

Take a look at the examples and decide for yourself.

One of the cool things about Second Life is that players can create new kinds of objects, by writing small programs in a special scripting language to describe how the objects should behave, and then launching objects into the world.

Things got really out of hand when the W-Hats created a doomsday device. It looked like a harmless little orb, but it was programmed to make copies of itself, repeatedly. The single object split into two. Then each of those split, and there were four. Then eight, and sixteen, and so on to infinity.

A highly amusing story this is.

I guess the correct term for this kind of thing is The law of unintended DSL consequences.

Please share similar stories, if you got them.

Module Mania: A Type-Safe, Separately Compiled, Extensible Interpreter

To illustrate the utility of a powerful modules language, this paper presents the embedded interpreter Lua-ML. The interpreter combines extensibility and separate compilation without compromising type safety. Its types are extended by applying a sum constructor to built-in types and to extensions, then tying a recursive knot using a two-level type; the sum constructor is written using an ML functor. The initial basis is extended by composing initialization functions from individual extensions, also using ML functors.

This is an excellent example of how the ML module language doesn't merely provide encapsulation but also strictly adds expressive power. It also demonstrates how a dynamic language (Lua) can be embedded in the statically-typed context of ML. Finally, it demonstrates that none of this need come at the expense of separate compilation or extensibility. Norman Ramsey's work is always highly recommended.

The papers presented at the International Workshop on Software Factories (held at OOPSLA 2005) are avialable online as well.

The Alloy Analyzer is a tool developed by the Software Design Group for analyzing models written in Alloy, a simple structural modeling language based on first-order logic. The tool can generate instances of invariants, simulate the execution of operations (even those defined implicitly), and check user-specified properties of a model. Alloy and its analyzer have been used primarily to explore abstract software designs. Its use in analyzing code for conformance to a specification and as an automatic test case generator are being investigated in ongoing research projects.

Alloy has been mentioned before, but with the recent discussions revolving around IDEs and questions about whether some kinds of checking belong in the language or in the tools surrounding the language, I thought it might be worth revisiting. In fact, it's tempting to suggest that we at LtU adopt a new category for stories: "Lightweight Formal Methods," and that we editors attempt to establish a continuum with respect to stories that fit the category. For example, Pierce makes the observation in TAPL that type systems are a particular kind of lightweight formal method, and that one of their benefits is that they're the only kind that are guaranteed to be used. Alloy falls in the "outside the language proper, but still incremental" category, and somewhere else on the spectrum you have full-blown theorem provers like Twelf, Coq, MetaPRL, et al. Does it make sense to try to unify some of the discussions about the boundary between languages and external tools under this umbrella?

Languages with implicit parallelism are easier to program in than those with explicit parallelism, but finding and efficiently exploiting parallelism in general-purpose programming languages by parallelizing compilers is hard. A compiler for a Very High Level Language, designed for a specific application domain, has more knowledge about its application domain and may use this knowledge to generate efficient parallel code without requiring the programmer to deal with explicit parallelism. To investigate this idea, we designed Multigame, a Very High Level Language for describing board games. A Multigame program is a formal description of the rules of a game, from which the Multigame compiler automatically generates a parallel game playing program.

An amusing DSL, and an interesting investigation of implicit parallelism.

Also see this later paper.

It would be nice to find a downloadable implementation, by the way.

The apps are built using PHP and a simple XML-vocabulary based DSL called XNHTML.

As I've been saying for a long time here and elsewhere, it's all about programmability these days, and as the Ning folks realise DSLs are a very good technique for achieving end-user programmability.

Seems to me they could have gone the extra mile, and eliminated the need for PHP altogether, but I guess that would be asking for too much...

On many occasions on this site we've discussed embedding a dynamic type checking scheme in a statically typed language using a Univ type. On many of these occasions, it's been suggested that this is an in-principle solution that would never be usable in practice, Turing tar-pit, etc., etc. Well, someone decided to put their money where our mouths are, and now we have Dynaml.

I've only briefly looked at the tutorial, but this definitely goes a long way toward demonstrating a plausible Univ embedding of a dynamic type system. Of course, I'd be curious to hear what everyone else thinks...

(from the caml weekly news...)

André Pang, Don Stewart, Sean Seefried, and Manuel M. T. Chakravarty. Plugging Haskell In (pdf). Proceedings of the ACM SIGPLAN Workshop on Haskell, 2004, pp. 10-21.

Extension languages enable users to expand the functionality of an application without touching its source code. Commonly, these languages are dynamically typed languages, such as Lisp, Python, or domain-specific languages, which support runtime plugins via dynamic loading of components. We show that Haskell can be comfortably used as a statically typed extension language, and that it can support type-safe dynamic loading of plugins using dynamic types.

Two of the authors also have a more recent paper (pdf) describing applications they've built using hs-plugins.

twill is a reimplementation of PBP, the "Python Browser Poseur"... The primary use for twill (as with PBP) is to do automated testing of Web applications via a straightforward declarative language. In addition to basic Web crawling, I wanted to be able to extend the language via Python, and I also wanted to be able to record things with maxq. Hence, twill.