Lambda the Ultimate

I'm currently designing a small, uniquely typed language for a masters project. So far the semantics is pretty well mapped out and I'm looking for a suitable backend to compile to.

Although the language has been designed as an imperative language with referential transparency, it can be translated fairly directly into Haskel, however doing so loses most of the benefits of having uniqueness typing, i.e. object lifetime can be determined at compile time meaning no garbage collection and safe destructive updates. I'd like to find a suitable backend/vm to compile to that will allow me to take advantage of these properties.

It would be nice to be able to include laziness and implicit parallelism too, although neither is essential and are perhaps beyond the scope of my project. Having said that, a backend that supports concurrent programming would be very useful, as uniqueness typing allows for an interesting model of concurrency without deadlocks or race conditions....

I can happily provide more concrete information on the language (I should really give it a name) if needed, I'm not sure of the kind of thing that's important to consider.

A previous discussion on this site talked about how linear languages can be compiled using stack machines and permutations, so some sort of stack based vm might be a good idea.

Thanks!

Reaction-time and eye-fixation data are analyzed to investigate how people infer the kinematics of simple mechanical systems (pulley systems) from diagrams showing their static configuration. It is proposed that this mental animation process involves decomposing the representation of a pulley system into smaller units corresponding to the machine components and animating these components in a sequence corresponding to the causal sequence of events in the machine's operation. Although it is possible for people to make inferences against the chain of causality in the machine, these inferences are more difficult, and people have a preference for inferences in the direction of causality. The mental animation process reflects both capacity limitations and limitations of mechanical knowledge.

Following the theme of yesterday's post this is another non-PL research paper that explores cognitive factors that might be relevant to programming language design.

The research in the paper nicely illustrates how different accounts of the cognitive processes involved in reasoning about the behavior of a mechanical system or model can be compared experimentally. The results suggest the types of inferences that are involved in mental animation of the type requested from the subjects, and how they are orchestrated.

The first section of the paper provides the general framework, and explains the notion of mental animation. A discussion of the generality of the results can be found at the end of the paper.

Those who find my last two posts too far removed from PL issues need not worry; I am not going to post more research of this type soon. Those who are intrigued by this research will be happy to know that a lot more is available where this came from.

Mixins, a very interesting post from Slava Pestov's Factor blog.

Factor's object system allows the following operations without forcing unnecessary coupling:

* Defining new operations over existing types
* Defining existing operations over new types
* Importing existing mixin method suites into new types
* Importing new method suites into existing types
* Defining new operations in existing mixin method suites
* Defining new mixin method suites which implement existing operations

That's pretty much what I want from an object-functional language.

I was wondering what people would consider Perlis languages, i.e. languages worth knowing because they should change how you think about programming. Obviously there is a lot of overlap between languages so what I'm looking for is a minimal set of established languages (by that I mean 10 years or older) that still provides a reasonably complete overview of different approaches to programming. My first try at a list would look something like:

Ada, C, Haskell, Java, Lisp, Smalltalk, Perl

Roy, Peter van (2009). Programming Paradigms for Dummies: What Every Programmer Should Know. In G. Assayag and A. Gerzso (eds.) New Computational Paradigms for Computer Music, IRCAM/Delatour, France.

This chapter gives an introduction to all the main programming paradigms, their underlying concepts, and the relationships between them. We give a broad view to help programmers choose the right concepts they need to solve the problems at hand. We give a taxonomy of almost 30 useful programming paradigms and how they are related. Most of them differ only in one or a few concepts, but this can make a world of difference in programming. We explain briefly how programming paradigms influence language design, and we show two sweet spots: dual-paradigm languages and a definitive language. We introduce the main concepts of programming languages: records, closures, independence (concurrency), and named state. We explain the main principles of data abstraction and how it lets us organize large programs. Finally, we conclude by focusing on concurrency, which is widely considered the hardest concept to program with. We present four little-known but important paradigms that greatly simplify concurrent programming with respect to mainstream languages: declarative concurrency (both eager and lazy), functional reactive programming, discrete synchronous programming, and constraint programming. These paradigms have no race conditions and can be used in cases where no other paradigm works. We explain why for multi-core processors and we give several examples from computer music, which often uses these paradigms.

I have not found this paper in the LTU archives, but I though it is likely of interest to this community. Of course, the author is well know here (e.g., his book Concepts, Techniques, and Models of Computer Programming). I like the bird's eye view of this paper.

Here's the paper submitted to the 2009 Symposium on Parallelism in Algorithms and Architectures:

Reducers and Other Cilk++ Hyperobjects