Lambda the Ultimate

D3 is a popular HTML5 visualization framework. While similar to other JS frameworks in its exposure of CSS/SVG, its enter()/exit() abstraction is an elegant leap for structuring code. Check out Mike Bostock's short and direct explanation Thinking with Joins:

Say you’re making a basic scatterplot using D3, and you need to create some SVG circle elements to visualize your data. You may be surprised to discover that D3 has no primitive for creating multiple DOM elements. WAT?

I particularly appreciated the practicality of this model for designing animated transitions. You can also check out the beautiful gallery of examples.

Has there been any PL research into languages where every semantically distinct program has exactly one representation in the source language? In other words, a language where for any given set of inputs, any change in the source text will create a program that for the same set of input produces a different set of outputs than the original program. Basically taking Python's "there should be one-- and preferably only one --obvious way to do it" philosophy to its logical extreme. I'm interested in how limiting this is on what you can express, since for any two equivalent algorithms only one of them could be written in the language. Is there an established technical term for this I can Google?

Hi there, I've been reading LtU for a while now, but I finally took the plunge and registered. I'm mostly self-taught and I can appreciate the quote by Dominic Fox on the Policies page. Hopefully, at worst I'm a newbie and not a wannabe. Anyways, I'm working on designing my own language, and I've actually settled most of the design choices, even started writing up parts of the compiler front-end.

Before I finally start setting things in stone though, I wanted to step back and make sure I'm not missing anything. I think it's interesting that the past few stories have been more about the "pragmatics" (if I can sneak in a linguistics term) of languages: adoption, tool-support, an active community. I found the comments to the story on R really interesting especially starting here.

I think Dennis Ritchie's advice on not expecting to become a superstar is apt too, but I figure if I'm going to put a lot into this project, shoot for the moon, right? When it comes to adoption though, I think Peter Gabriel's "Worse is Better" makes sense. Needs either arise or remain that other languages don't fill. It's almost evolutionary, where a new niche opens up and the first language into it, even if it's far from perfect, gets the opportunity and support to adapt.

I've read a lot of opinions that handling concurrency well is the current big hurdle to clear, but I've also read a few logical arguments that concurrency is a hyped issue. I'm far from the most experienced or smartest about this so I was wondering if anyone, based on their own research or work, had a different opinion on what the great, unfilled niche is. My own impression is that a toolchain and primitives that help simplify parallelism over data and air-tight security are actually stronger needs (like E?), but I could see concurrency being valuable for real-time systems.

Obviously, I'm going to make the language as complete as possible, but there's a point past which you just burn yourself out. If there are any articles or papers I should check out, I'd really appreciate it. Besides that, I hope this isn't too long or off topic, and I look forward to being part of the site.

This short article describes how predicates are handled in Modern Eiffel.

In a similar manner as with functions(described in Functions ... ), predicates can be ghost predicates and/or higher order predicates.

System F_ω appears impredicative, but I'm wondering if there is an easy way to embed it into predicative dependent type theory by inferring bounds on universes. Also, if anyone can provide an example of a System F_ω term that would be rejected by Coq's typical ambiguity resolver, that would be helpful to me.

Any references or thought are appreciated.

FP Days is a practically-focussed event for people working with or interested in learning Functional Programming. We're looking for enthusiastic speakers to share their practical experiences of Functional Programming. Accepted speakers pay no conference fees. You don't have to be a big name and we encourage and support first-time speakers willing to share their experiences.

CALL FOR SPEAKERS - SUBMISSION DEADLINE JULY 6TH

We are seeking high-quality session proposals covering any aspect of functional programming.

Hands-on sessions, experience reports, tutorials, panels and other interactive sessions are particularly encouraged although more theoretical sessions are also welcome.

In addition to free entry for the conference, being a speaker gives you a unique opportunity to present your viewpoint to our audience and get feedback.

MAKING A PROPOSAL

Making a session proposal isn't difficult. All we require is some basic information on the session you plan to run - enough to judge that it would be of value to our participants.

Please visit http://www.fpdays.net/fpdays2012/index.php for more information.

Rich Hickey's post on Reducers - A Library and Model for Collection Processing

By adopting an alternative view of collections as reducible, rather than seqable things, we can get a complementary set of fundamental operations that tradeoff laziness for parallelism, while retaining the same high-level, functional programming model. Because the two models retain the same shape, we can easily choose whichever is appropriate for the task at hand.

Many software developers are turned away from verification techniques because providing proofs for algorithms seems something horrible and pureley theoretical to them. A newcomer to a proof assistant like Coq or Isabelle needs at least two weeks to be able to prove some simple theorems. And it is difficult to realize that proving has something to do with programming.

In order to provide software verification for the masses a different approach is necessary.

If one gains more experience with proofs one realizes that writing a proof is not very different from writing a program. Currently I try to exploit the technique of writing a proof like a program. This led to the notion of proof procedures. With proof procedures there is no need to issue proof commands to some proof engine to manipulate the state of the engine. One just writes assertions (i.e. boolean expressions) in a step by step logical manner. A proof look like a procedure.

The article Proofs made easy with proof procedures describes the basic approach.

A paper in ICSE 2012 by Abram Hindle, Earl Barr, Zhendong Su, Mark Gabel, and Prem Devanbu. Abstract:

Natural languages like English are rich, complex, and powerful. The highly creative and graceful use of languages like English and Tamil, by masters like Shakespeare and Avvaiyar, can certainly delight and inspire. But in practice, given cognitive constraints and the exigencies of daily life, most human utterances are far simpler and much more repetitive and predictable. In fact, these utterances can be very usefully modeled using modern statistical methods. This fact has led to the phenomenal success of statistical approaches to speech recognition, natural language translation, question-answering, and text mining and comprehension.

We begin with the conjecture that most software is also natural, in the sense that it is created by humans at work, with all the attendant constraints and limitations—and thus, like natural language, it is also likely to be repetitive and predictable. We then proceed to ask whether a) code can be usefully modeled by statistical language models and b) such models can be leveraged to support software engineers. Using the widely adopted n-gram model, we provide empirical evidence supportive of a positive answer to both these questions. We show that code is also very repetitive, and in fact even more so than natural languages. As an example use of the model, we have developed a simple code completion engine for Java that, despite its simplicity, already improves Eclipse’s built-in completion capability. We conclude the paper by laying out a vision for future research in this area.

More a visionary paper, but seems to be the best work I've seen so far on how to apply ML to programming.

Hi all!

I'm busy designing my third language (or, redesigning the first, depending on how you look at it). I changed Feather to be a heapless functional programming language. Primarily, this means there is no need for a garbage collector. Programs for embedded devices that have real-time constraints stand to benefit the most from this. With any luck, we could get a subset to compile to some GPUs.

Here's the design as it is. Note that I use underscores for tabs whitespace due to forum restrictions -


The Feather Programming Language is a heapless functional programming language for real-time software, especially on embedded devices. It is a compiled language with a Hindley-Milner type-inferencing algorithm and strict function argument evaluation.

Miscellaneous rules -
import… // very similar to Haskell's import, but much simpler and less error prone
Module.fn // qualifies fn with module name. A.b != a . b due to whitespace (and apparently capitalization). In the expression Module.(+), the parens are required for symbolic operator qualification.
shadowed fn // calls the function that the current function is shadowing… might be a special form
rest… // the rest parameters with name rest
rule: indentation defines scope
rule: symbolic operators like + and * have specifiable precedence and associativity, textual ones do not
rule: symbolic operators take precedence over all textual operators
rule: symbolic operators can be sequenced and so can textual ones, but they cannot be sequenced together in the same function specification.
rule: 'if' is a major word since it's the beginning of a sequence and 'then' and 'else' are minor words since they're in the tail of a sequence.
rule: symbolic chars cannot be mixed with alphanumeric chars in the same word, and neither can be mixed with delimiters such as (, ), {, }, [, and ]. Sadly this means we can’t have meaningful (|banana clips|) or [|oxford brackets|].
rule: words in an ongoing sequence take precedence over a single word or words beginning a new sequence.
rule: the point where a function is injected is its application site, even if it is partially applied with no arguments, like map in the expression fn (map).
rule: purity means more than just no immediate side-effects; it means referentially transparent.
rule: expressions should generally be readable from left to right and top to bottom.
rule: there are 3 types of function purity – pure, impure, and dependent. Only higher order functions can be dependent. A dependent function resolves to pure or impure depending on how it is invoked. If one or more of its parameter functions is impure, it becomes impure. Otherwise, its purity depends on whether it calls other impure functions.
rule: a function with impure contents can be forced to be have a pure type with the pure function modifier. This allows most pure functions to be inferred, and the remaining be manually declared as such.
rule: all module, type, protocol, and type / data constructor names start with an uppercase letter. This makes pattern matching much easier to use (this is what Haskell does).
rule: the only time you need to qualify a name with the module is when it collides with another imported name.
rule: operator precedence and associativity is the same as in C, but with floating point precedence values (is that a good idea if the embedded systems might not have floating-point acceleration?)
rule: like python and its recommended 'pythonic' style philosophy, there is a similar recommended philosophy in Feather. In Feather, there is always a single best way to do any one thing, and it should be obvious. This won't always be achievable, but is a good language goal.
rule: textual operators should typically be written in an active voice.


So anyways, I'll keep designing this until I get a chance to start implementing it. I've already implemented a pure functional programming language with F# (see AmlProject at SourceForge), so I've got enough confidence to start on this one. I'm thinking I'll use LLVM to build the compiler.

Hopefully this language will finally allow us to program stuff like games for embedded devices and console in a functional style.