Archive for May, 2012

In the May/June 2012 issue of Internet Computing, Brian McKenna provides us with an excellent guest “Functional Web” column about Roy, a statically typed functional language that targets the JavaScript platform. Brian’s goals with Roy are to take advantage of static typing and functional programming to provide better safety and productivity for web programmers without forcing them to give up the ubiquitous JavaScript platform. Here’s the PDF of Brian’s clear and well-written article, loaded with informative code examples.

LaME is an interactive venue for exposing, evaluating, and developing programming language support for concurrency. This workshop provides a forum for the proposal and discussion of creative ideas that spur the development of innovative or improved concurrency models, languages, run-time systems, libraries and tools for multicore programming.

Space at the workshop is limited. We can ensure admission only to those submitting accepted position papers, programming challenge solutions, or other presentations.

Position papers (of up to 2 pages) describing ongoing work of attendees. Position papers will be reviewed for scope and relevance, and distributed to all attendees before the workshop. Attendees submitting position papers relevant to the workshop sessions on open issues in LaME may be invited to present brief (two-slide) synopses of their ideas and work on the following. (Authors should indicate which if any session their position papers address.)

Type Systems, including those for isolation, state, and effects

Intermediate program representations, including those supporting optimizations across tasks, memory locality

Solutions to the LaME’12 programming challenge, described below. A session at the workshop will be devoted to brief presentations of solutions and their implications for the design and implementation of programming languages and parallel program development.

Programming Challenge

We solicit solutions to all or part of the following challenge, designed to showcase the expressiveness of different parallel language abstractions. The challenge is in two parts, one algorithmic and one engineering parallelism into a real-world context. Solutions may target either or both parts.

Solutions should include source code (ideally complete, but this is not required) as well as a short paper discussing the benefits and drawbacks of the approach. Comparisons to alternative approaches are welcome.

While the primary focus of this challenge is on expressiveness of the language, library or other abstractions used in the solution, evaluations showing the scalability and performance of the proposed approach are encouraged to show the performance that can be achieved with the approach.

The paper should be at most 4 pages. Code and papers will not be formally published, but will be archived on the LaME website. Solutions to the challenge problem will be presented and discussed at a workshop session.

Part A: Parallel Algorithms

The first challenge involves expressing algorithms cleanly. Prospective solutions will implement one or more of the benchmarks from the Problem Based Benchmark Suite. This open source suite describes a number of common real-world problems in terms of the function they implement and not the particular algorithm or code they use, and are thus a useful way to compare different programming languages, methodologies, and algorithm designs.

A description of the problems in the benchmark suite, together with sample implementations and sample inputs, is available at:

The second challenge involves putting parallelism into a real-world context. While expressing the core of an algorithm is important, equally important is getting the data from the world, into an algorithm, and back out into the world. Desirable characteristics include code that is short, clear, and efficient.

Prospective solutions will show how to get parallel data from some public source, process it in parallel, and display the output in some meaningful way. The processing itself may be a solution to Part A or it may be any other parallel algorithm. Data sources to consider include Tim Bray’s Wide Finder and Wide Finder 2 benchmarks or one of the research-quality data sets described here: