Lambda the Ultimate

The sixth annual International APL Problem Solving Competition is now live!

Dyalog Ltd invites students worldwide to put their programming and problem-solving skills to the test by using any APL system to develop solutions to ten questions and solve a series of problems. This is a contest for people who love a challenge and learning new things for fun, with the added bonus that you can win one of 43 cash prizes totalling $8,500, including a grand prize of $2,500 and a trip to Eastbourne in the U.K. to attend the annual Dyalog Ltd user meeting in September 2014.

For the rules and eligibility criteria and to enter the competition, go to http://www.dyalogaplcompetition.com/.

If you have friends who love a challenge and learning new things for fun, or you know students who might be interested in participating, then please recommend this contest to them.

The deadline for submitting solutions is 6 August 2014. Winners will be announced on 18 August 2014.

Good luck and have fun!

https://github.com/yallop/icfp2014-papers/blob/master/README.md

I want to produce traces of the type derivations for compositional type inference to help debugging programs. Currently the reports look like this:

var ---------------------------------------
x : {x : a} |- a

var ---------------------------------------
y : {y : a} |- a

x : {x : a} |- a
y : {y : a} |- a
app ---------------------------------------
(x y) : {x : (a -> b), y : a} |- b

var ---------------------------------------
z : {z : a} |- a

(x y) : {x : (a -> b), y : a} |- b
z : {z : a} |- a
app ---------------------------------------
((x y) z) : {x : (a -> (b -> c)), y : a, z : b} |- c

However repeating the typings in each derivation seems a bit of a waste of space. I am thinking I can just reference which rule is used and number the statements, a bit like a theorem proof. Something like:

1) var |= x : {x : a} |- a
2) var |= y : {y : a} |- a
3) app (1) (2) |= (x y) : {x : (a -> b), y : a} |- b
4) var |= z : {z : a} |- a
5) app (3) (4) |= ((x y) z) : {x : (a -> (b -> c)), y : a, z : b} |- c

Does this seem a reasonable notation? it the use of the double-turnstile "|=" a misuse of notation? Is there a better way to write this?

Hi all!

I'm experimenting with constructing a programming language for artificial intelligence programming. I want it also to be enabled for regular application programming. Right now i have thought through the stateless part, meaning that I have a rough definition of underlying stateless machine.

In real world there are also constructs that require statefull machines to hold some knowledge, but I'd hate to extend current language definition with additional statefull stuff that complicates the language that is now so simple without it.

So, I'm wondering are there known methods or new ideas to describe states inside stateless machines?

Tx :)

Contains odors of: Oberon and Actor Model type (E, Erlang, etc.) languages.

The Concepts of Zonnon:

• design support for ‘programming in the large’
• a modern object model that supports concurrency: activities in objects replacing passive method calls
• formalised interaction between activities (dialogs)
• good for structured and OO programming styles for a wide range of applications … OS to Business
• retain the simplicity of PASCAL, Modula-2, Oberon family of languages
• support multi-processor and distributed systems
• support inter-operation with other languages and their libraries
• produce a .NET Compiler, IDE, Test Suite and concise Language Report (40 Pages)

Some things: Facets: Allowing objects to not be forced into one major role; Syntax based 'dialogs' govern concurrent interaction; Object level concurrency/threads; Statement level concurrency; 40 page language specification.

When I skim the slides and see the code and statements about the approach to concurrency, it looks to me off the cuff that it would just make deadlock even bigger and more hairy. :-}

Can we have a polite, orderly and short discussion of the political, social, institutional aspects of the Swift language? This thread is the place for it.

A blog post from Netflix about Self-Assembling Components.

But what if you could have functions that self-assemble? What if processors could simply advertise their inputs/outputs and the wiring between them were an emergent property of that particular collection of processors?

Hi, fellow language enthusiasts!

I recently finished an experimental, fairly simple, OCaml implementation of refined types. Refined types support logical predicates in function parameters and return types, for example:

/ : (int, i : int if i != 0) -> int

random1toN : (N : int if N >= 1) -> (i : int if 1 <= i and i <= N)

length : forall[t] (a : array[t]) -> (l : int if l >= 0)

get : forall[t] (a : array[t], i : int if i >= 0 and i < length(a)) -> t

Refined types are checked by an external automatic theorem prover (Z3), and can prevent many common software errors, such as division by zero and out-of-bounds array access. Given correct refined types on functions alloc and memcpy, they could even be used to prevent Heartbleed bug!

Read more about it (and see the code) here! Any comments are welcome.

I thought this might be of interest to LtU readers:

Nitra is a language for describing grammars, and the abstract syntax trees to represent them. It is also a build tool to compile the grammars into parsers, and generate the classes required to represent and navigate the AST. And it’s also a set of language services that use the grammar to provide automatic syntax highlighting, outlining and brace matching.

What’s more, Nitra’s grammars are designed to be extensible and reusable. A simple example would be the base building block grammars that ship with Nitra, such as Whitespaces and CStyleComments. Both clearly useful in many languages, and can be simply included and reused in a larger grammar.

The announcement is here. It's available in GitHub and was released under a simplified BSD license.

I've dreamed / complained about the lack of such a thing for ages. Glad somebody with brains and motivation has started to do something about it: ML-TID: A Type Inference Debugger for ML in Education.

Student programmers can struggle to understand how their code is wrong, while expert programmers become frustrated when the safety mechanisms of a language render programming more cumbersome. Across the spectrum of languages, those with type inference encourage the user to elide information that would otherwise catch errors at their source, making them more difficult to resolve.
In this paper, we present a novel debugging tool for ML that should lower the barrier to entry. ML-TID1 exposes a standard debugging UI that allows the user to step-through the ML type inference algorithm in a controlled environment. We present details of the concept and implementation and results from a study of 20 undergraduates.