Lambda the Ultimate

An excerpt from the CfP, http://days2011.scala-lang.org/node/91

This workshop is a forum for researchers and practitioners to share new ideas and results of interest to the Scala community. The second annual workshop will be held at Stanford University in the San Francisco Bay Area, on Thursday the 2nd of June 2011, co-located with Scala Days 2011 (2nd-3rd of June).

The workshop takes place as part of the Scala Days conference, http://days2011.scala-lang.org/

Cheers,

Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/

Hi all!

I've been reading LtU for a couple of years now, and although I must confess that a fair amount of the highly specific research goes over my head, it's been an invaluable resource for furthering my own explorations in PLT, and deeply thought-provoking even when the finer points may escape me. As such, I've come to respect the LtU community very highly, and I strongly value the opinions of those who have a deeper grasp of this subject than I do. I believe that immersion is the best way to learn - sink or swim, if you will.

In my own career I've done a fair amount of work on DSLs and embedded DSLs for various purposes, most recently games development; this has been a fascinating brush with PLT and the real-life implications of language design and implementation designs. However, I consider it just that - a light contact. General-purpose language development is a completely different ball game, and despite my decent amount of experience in the DSL realm, I'm still a total neophyte when it comes to building a true general-purpose language.

That brings me up to Epoch, my language-in-the-making. Of all the hobby projects - and professional tasks - I've engaged in over the years, this is easily the most exciting, fascinating, and challenging. I hope I can glean some serious education from the LtU community as I present my pride and joy!

Epoch - A General Applications Language for Asymmetric Multiprocessing
I didn't just set out to make a language for the fun of it, although it has been an immensely enjoyable ride. The primary goal of Epoch is to harness modern asymmetric multiprocessing hardware opportunities. Symmetric multiprocessing (SMP) is becoming increasingly commonplace in the form of multi-core processors, and this proliferation shows no signs of slowing any time soon. However, asymmetric multiprocessing (AMP) - the presence of non-homogeneous computation devices within a single computer - has actually been around even longer, and remains one of the most untapped computation resources we have outside of the games industry.

AMP heavily features in entertainment software, in three forms: the primary CPU for main game logic, the GPU for video rendering and effects, and accelerated audio effects from dedicated sound card hardware. In recent years, the introduction of dedicated physics accelerators has added another dimension to the puzzle, and the explosion of specialized processors such as Cell, Tesla, and Larrabee promises to complicate matters even further.

The key observation of the Epoch language project is that, by and large, the implementation of interesting algorithms on various forms of hardware should remain independent of the specific details of operation of those hardware elements. We can divide the processing hardware common in AMP situations into a few families, and identify effective means of representing algorithms for each family. In this way, programmers need only understand the family of processor they intend to work with, and learn how to express algorithms for that family itself - there is no need to learn a half-dozen machine or architecture specific instruction sets or languages in order to tap all of the available hardware.

Another key attribute of Epoch is its ability to dynamically react to available hardware and relocate running code according to the physical resources at hand. For instance, the VM may notice the presence of a supported GPGPU system such as an OpenCL-compatible device, and offload specially tagged code from the main CPU to that GPGPU for better performance. It is the responsibility of the programmer to tag his code correctly, but once this is done, he can be assured that his program will flexibly take advantage of any and all resources available on whatever hardware the program runs. This can even be extended to generic SMP via multithreading, or distributed computing across local or wide-area networks, given proper infrastructure in the VM itself.

How is this all relevant to PLT?
Although Epoch's focus, from a practical standpoint, is multiprocessing/concurrency in various forms, I don't intend to just write another minor variant of C. Instead, I'm drawn to the host of modern languages (and even older ones!) with rich feature sets and philosophies, that make development of nontrivial software much more pleasant and robust.

As such, my real goal is to create a language that is both accessible to the current generation of systems and applications programmers who are accustomed to C (and to a lesser extent C++) for their work, and simultaneously appealing to those programmers with experience in much more expressive and powerful languages, notably Common Lisp, Scheme, ML, Haskell, Ruby, and so on.

This is where LtU comes in, in a big way. My own grounding in PLT is purely that of a curious autodidact; I have no formal training in PLT or indeed in programming in general. Although I strive to understand and internalize the theory and best-practices of formal and academic programming and PLT, I can only be honest and say that I know there must be significant gaps in my knowledge.

My goal with posting this here is not to publicize or evangelize for Epoch, but to increase my own understanding both of the theoretical foundations upon which I am working, and of the requirements and desires of real-world programmers who may one day find Epoch an appealing toolset upon which to develop their own work.

A quick overview of Epoch
In a nutshell, I can describe Epoch as follows. Please note that a lot of this is just planned for the future; I'm only just now working my way up to the 11th iteration of the core compiler and VM, so there's many areas that still need shoring up or even first implementations.

• Statically, strongly typed
• Syntactically simple and consistent, although not quite to a Lisp extreme
• Statically, lexically scoped
• Supports both procedural/imperative and purely functional paradigms, via tagging of "pure" code
• Designed to marshal readily to C APIs/ABIs
• Supports object-oriented paradigms with rich "access control" semantics and named subtyping
• Rich support for algebraic datatypes and type inference
• Value semantics for variables with optional reference semantics
• "Null" references are strictly forbidden; algebraic datatypes and Empty/Nothing types are required for expressing optional references or optional function parameters
• Supports closures and higher-order functions
• Fully garbage collected
• Intended to be execution-model agnostic: i.e. can run under a VM, native code, etc.

And of course I'm sure there are more details I've forgotten!

The Epoch Language Project on Google Code
The full project can be found at epoch-language.googlecode.com. Please feel free to roam around the source repository, issue tracker, and wiki; if you feel exceedingly generous, download Release 10 of the SDK and play around a bit! Everyone is welcome to report issues or other feedback.

Again my goal here is to further my own education and understanding a bit, and I believe one of the best ways to do that is to open my work up for criticism by people who know more than I do!

Thanks for taking the time to check this out, and I look forward to hearing from LtU.