Lambda the Ultimate

I'd be curious to know what people's opinions are on the matter of symbol visibility, and whether there are any new and fresh ideas in this space.

Now, you might think that symbol visibility would be a rather dull and pedestrian topic for a language theorist - few research papers on language design even mention the topic. However, I think that this is actually a very interesting area of language design.

Limiting the visibility of symbols has immense practical value, especially for large code bases: the main benefit is that it simplifies reasoning about the code. If you know that a symbol can only be referenced by a limited subset of the code, it makes thinking about that symbol easier.

There are a number of languages which have, in pursuit of the goal of overall simplicity, removed visibility options - for example Go does not support "protected" visibility. I think this is exactly the wrong approach - reducing overall cognitive burden is better achieved by having a rich language for specifying access, which allows the programmer to narrowly tailor the subset of code where the symbol is visible.

Here's a real-world example of what I mean: One of the code bases I work on is a large Java library with many subpackages that are supposed to be internal to the library, but are in fact public because Java has no way to restrict visibility above the immediate package level. In fact, many of the classes have a comment at the top saying "treat as superpackage private", but there's no enforcement of this in the language.

This could easily be solved if Java had something equivalent to C++'s "friend" declaration, the subpackages could then all be made private, and declare the library as a whole to be a friend.

However, I wonder if there's something that's even better...

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.

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.