Lambda the Ultimate

Another version of my BNFT (Backus Naur Form Transformation) - now in javascript (previous in java and C++).

The tool can be used to quickly set up a grammar for your shiny new DSL and translate it into textform (typically javascript).

Javaversion was mentioned here: http://lambda-the-ultimate.org/node/3610

Javascript demo currently sports examples of Brainfuck and Turtle.

Github source is here: https://github.com/phook/BNFT

Online test console is here: http://phook.dk/BNFT/BNFT testbed.html

SNAPL: The Inaugural Summit oN Advances in Programming Languages

Calling all Programming Language Researchers!

The programming languages community has several excellent conferences. However, conferences are focused on incremental bits of novelty. We want to create a new kind of venue that complements these: to present and discuss big-picture questions and long-running research programs; to view progress along the long arc of a research effort. Other communities do this better (e.g. the CIDR series in databases).

To this end, we are putting together the inaugural Summit oN Advances in Programming Languages (SNAPL). We hope that the biennial SNAPL will grow into a venue where our community comes to enjoy talks with inspiring ideas, fresh insights, and lots of discussion.

For the event to succeed, we need the stars in the community to submit. Please start working on your paper.

Important Dates:
Submission: January 6, 2015
Decisions announced: February 20, 2015
Final versions due: March 20, 2015
Conference: May 3-6, 2015 (Asilomar, California, US)

So there are lots of things people here have already been exposed to, but a lot of them seem to fail to get much traction. Thus I very much appreciate this talk by David Nolan which helps "sell" more of the FP side of the FP vs. OO wars if you will, via Om: Clojurescript for React.

(Of course, he has to go and spoil it all by (1) selling AOP as well, and (2) insufficiently stressing the frustrations of trying to do these things in the Real World... but I guess I can't expect perfect nirvana to descend upon all people everywhere.)

A short position paper that tries to motivate managed time by contrasting it with data flow approaches; to be presented at SPLASH's REBLS workshop; abstract:

Event-driven programming avoids wasting user and CPU time, but is difficult to perform since program control flow is necessarily inverted and twisted. To make reactive programming easier, many advocate burying control flow within abstractions that are composed via data flow instead. This might be a mistake: data-flow has issues with expressiveness and usability that might not pan out. Instead, control flow could be re-invented to hide the adverse affects of CPU time while preserving expressiveness and directness

Announcing the 2015 edition of the OBT workshop, to be co-located with POPL 2015, in Mumbai, India. Two-page paper submissions are due November 7, 2014.

From the web page (http://www.cs.rice.edu/~sc40/obt15/):

Programming language researchers have the principles, tools, algorithms and abstractions to solve all kinds of problems, in all areas of computer science. However, identifying and evaluating new problems, particularly those that lie outside the typical core PL problems we all know and love, can be a significant challenge. This workshop's goal is to identify and discuss problems that do not often show up in our top conferences, but where programming language research can make a substantial impact. We hope fora like this will increase the diversity of problems that are studied by PL researchers and thus increase our community's impact on the world.

While many workshops associated with POPL have become more like mini-conferences themselves, this is an anti-goal for OBT. The workshop will be informal and structured to encourage discussion. We are at least as interested in problems as in solutions.

I am slowly working my way up to an understanding of separation logic and one thing I have not seen with separation logic is a transformation into functional code with immutable data structures.

With normal imperative code you just wrap a big fat monad around everything and there is a straightforward transformation into functional code with immutable data structures.

The disadvantage of a big fat monad is that you loose the ability to reason about parts of the program that have side effects but are independent of each other. I would expect therefore that smaller monads that could be split and combined by the rules developed for separating logic and the separating conjunction would exist.

Does anyone know if anyone has already research that? Or perhaps I am making an elementary error in my reasoning?

I'm trying to decide how I want to approach the issue of immutability in my language. So far, I've identified three general approaches.

Obviously, there are the purely functional languages, in which there is no mutability at all. I'm not interested in that approach, mainly because my focus is on multi-paradigm programming and that approach is too narrow for me.

The second approach is that used by C++, where 'const' is a type modifier - that is, a mutable type can be declared read-only after the fact.

The third approach is that taken by Java and many other languages where there are separate mutable and immutable types, which may conform to a common interface but which have separate implementations. For example, you have ArrayList and ImmutableList, both of which implement the List interface.

An advantage of the Java approach is that the immutable implementations can in many cases be simpler and more efficient than their mutable counterparts. A case in point is ImmutableList, which has an optimization whereby empty lists are represented by a reference to a static singleton instance.

On the other hand, it's extra work to have to implement two versions of every collection. That extra work isn't a problem for the most commonly-used containers, but for the long tail of specialized and possibly application-specific types it can be a significant burden.

C++ on the other hand has it's own version of the 'double work' problem, whereby a lot of classes end up having to implement two versions of many methods, a 'const' and 'non-const' version. However, this can be solved by language design - a 'conditional const' type modifier which is const only if the enclosing type is also const. This allows many of these double-definitions to be collapsed.

However, you still have the problem of maximizing efficiency of container implementations. Suppose I have a C++ class X that internally contains a vector. Adding the const modifier to X doesn't switch the implementation of the vector over to a more efficient, immutable version; And even if the language supported it, it wouldn't be very efficient because now you have to add a level of indirection between X and the vector (using virtual methods or some other technique) so that X's implementation can switch between the mutable and immutable implementation of vector based on whether X is mutable.

So I'm wondering if there are any other interesting approaches out there, or if there's a sweet spot that I'm missing.

As of about a week ago, Jonathan Blow (creator of various well received games such as Braid as well as various PL efforts) has pair of talks on twitch.tv (later both put on youtube) where he issues a call to arms for game developers to design a new programming language around their concerns. He discusses what he sees as some of the shortcomings of existing languages that are supposed to be C++ replacements, and some of the requirements he feels game devs have. There was a Q&A session as well.
The talks are more practical than PL theoretical, but interesting (and occasionally frustrating) never the less.

Meredith tweets under the handle @maradydd and contributes much to the tiny niche comprising the intersection of type theory and security. For example:

1. She shares links to and comments upon interesting contentshe summarises a 1964 post of Doug McIlroy's asserting four key failures of programming languages. (To recast these concerns as desiderata, I call these the McIlroy Systems-PL Minimum);
2. Her retweets are sharp, e.g., on requirements gaps in formal specifications of programming languages; and 'It’s almost as if basing systems around an untyped programming language is a bad idea';
3. And she promotes worthy things like the @typetheorypodcast and neat little sequent calculus tutorials.
   

The presentation of Kaya at the Future of Programming Workshop at the Strange Loop conference.

Kaya is declarative like SQL, reactive like a spreadsheet, and a spreadsheet metaphor is used to render powerful, expressive data structures. Code is not written in a text editor, but instead you compose applications in a spreadsheet-like editor. The resulting contextual nature ameliorates some of the typical need for control structures, and leads to a more natural way to compose applications.