Lambda the Ultimate

It seems effect types are things people want, but few languages have managed to reify them, make them something we can all use. (Like, in -- cough cough -- Java et. al.) Any thoughts on how/when it will get to be more mainstream? Good enough that you'd risk using in production (at least w/in a group that is a little on the cutting-edge)? What things should a decent effect system support? Not only null checks I hope. (I was wondering about, via 'pilud' list, is how to rigorously handle immutable/mutable conversion/interaction.) Or are we just stuck with monads and related transformer boilerplate (and confusion to people like me)?

• Effects in Idris (esoteric).
• Eff (in progress, academic).
• DDC (rip).
• Deca for pointers (limited).
• Links and DBs (limited).
• FX-91 back in the day (rip).

Everyone (e.g. in the LtU discussion back from 2010) seems to assume that first-class environments in a Scheme-like lexically scoped language are sufficient to implement all known module systems and then some. Still, it strikes me that implementing renaming of imported bindings (R[67]RS and Chicken (rename), Racket (rename-in)) with just first-class environments is impossible in the presence of mutability, even if foreign code is forbidden from mutating things inside the module. Even (only)-style shadowing is impossible without built-in support specifically for it in addition to plain environment inheritance. Introducing all this into environment semantics makes the whole idea look much less clean than it initially did. So, is this better done with stronger things like first-class locations? Or am I missing something obvious?

There are suggestions that MIT Scheme indeed implements its module system using environments, but I couldn’t really understand how (and whether) it handles this issue. The description in the Kernel language report is the best reference I could get on the topic.

Finally, note that this question is orthogonal to whether mutating exported bindings is a good thing to do from the stylistic point of view. If a language has mutability and a module system, it’d better be consistent in how they interact — a negative example here being the behaviour of bindings created with from module import ... in Python.

Lobster ( http://strlen.com/lobster ) has been released on GitHub ( https://github.com/aardappel/lobster ). It is a language that could be general purpose, but currently is specifically targeting game programming, with built-in support for OpenGL / SDL / FreeType.

The language looks similar to Python at first glance, but really is its own blend of fun features: a syntax centering around making higher order functions & function values look & function as much as possible like built-in control structures (terse, and with non-local returns), coroutines, multi-methods, vector operations, optional types, optional immutability.

The design did not have any lofty goals of programming language research or innovation, instead, it indulges in simply being a fun language for the typical code written in it (small-medium games).

I guess this question was already discussed here on LtU, but I did not find it.

When is it necessary and rewarding to design a domain specific language, instead of creating a library for some general purpose language? Is it just more convenient syntax? What are the aspects that should be taken into account on deciding this question?

I've been working on this note to describe the type system I've been working on that collects many of the ideas I've been working on (see here, here and here, and here). Now that I actually have something fairly complete, feedback would be appreciated. I'm currently implementing this in my live programming work and it will hopefully be in my next prototype, though the ideas are relatively unrelated so far. Abstract:

This note introduces a novel type system that is static, annotation free, and object-oriented with class-like mixin-style traits. Inference in this YinYang type system diverges significantly from Hindley-Milner by computing graphs of assignment relationships rather than principal types, hiding values and preserving connectivity in encapsulated graphs. Inferred types are then useful not only for checking purposes, but also in allowing code completion to specify program functionality in a relaxed order.

Again, the note is hosted here on GitHub.

This paper [pdf] defines a set of principles for designing cognitively effective visual notations.

(i'd quote more but i can't copy and paste and i'm already tired of typing.)

C's type system can be seen as a constraint checker; Haskell's as a constraint solver. If you had a general purpose constraint solver at compile-time what could you use it for other than type checking?

Suppose I allow multiple definitions of routines/classes in a programming language, with the caveat that anything multiply defined must have identical semantics (identical interface, identical results, identical effects if non functional) and different syntactic structure in every definition.

Then have the development environment (but probably not the runtime environment) run multiple copies of the program, synchronizing just before and after each call to the multiply-implemented routine or class. If different results/effects are detected by a comparison of the program states at return time, halt with an error message. Clearly, if both (or all) implementations are supposed to have the same semantics, then when results/effects diverge, it is evidence that at least one has a bug.

It seems unlikely, though possible, that both would have the same bugs, leading to rare "false positives" in which the test suite completes without error despite a lurking bug. False negatives however -- where the test suite halts with a comparison error despite the tested code having identical semantics, would be eliminated. Every time the alarm goes up, there is definitely something wrong.

Refactoring would also be easier; when a new implementation is supposed to provide the same services to the rest of the program as the old one, you could run them simultaneously rather than serially through a test suite, and make sure that, in fact, they do. This would also mean you can add test cases spontaneously and run them parallel, rather than having to reconfigure your program (twice!) to test both implementations against each other on a new test case you add/find after the first run of testing.

A semi-random thought about development environments. More a programmer convenience, perhaps, since you could do the test and comparison by hand as well, but nevertheless an important complement to static analysis. It would allow you to test things well beyond the ability of a typical type analysis to make sure that they are and do, in fact, what you want.

Anyone seen something similar, or is this actually an original idea?

This post evaluates the programming languages ATS, C#, Go, Haskell, OCaml, Python and Rust to try to decide which would be the best language in which to write 0install (which is currently implemented in Python). Hopefully it will also be interesting to anyone curious about these languages.

i thought the "safety" portion of the evaluation was particularly interesting.

(overall, i find the review depressing: there's no good programming language, i guess.)

On a lighthearted note, if you're considering pursuing a PhD you might want to take this simple test to see if you're a good candidate for this lifestyle.