How to point in code

In my previous post, I explored why deixis is helpful, how it shows up in our language, and how its use in source code is hampered by limitations in our current programming ecosystems.

I promised I’d explain how we could remedy this problem to increase the expressiveness of our code… That’s what this post is all about.

It starts with names

The magic that makes the web “hyper” is not really in tags. Sure, we use ... to point at something–but there are other ways to point. As I said in my previous post, line numbers point. Method names in source code point at their decl or their impl. Statements like using namespace std point. Names of build-time dependencies in maven pom.xml files point.

The real magic is that the web has so many things to point to. It has names (notice where “name” appears in the previous paragraph). Every resource–even ones that are dynamically generated–has a URL. Individual paragraphs or tables or images inside a resource can have names, which lets us point to them, too.

We value names.

image credit: xkcd.com

So, if names are so valuable, part of how we make code more “hyper” is to increase the availability of names. Here are some ways to do that.

Continue reading

Introducing Marks

In my previous two posts (here and here), I described how and why programming languages can’t talk about many issues that affect programmers–important issues like product requirements, design constraints, intellectual property, and more. I also inventoried the mechanisms that extend the semantics of languages today, and explored why those mechanisms have limited value. If you haven’t read those posts, please do; what I say next won’t make a lot of sense without that foundation.

In the intent programming language that I’m creating, the solution to this problem is called “marks” (a name which alludes to linguistic markedness). Marks play a role somewhat analogous to adjectives and adverbs in human language; they are crucial enrichers. They resemble decorators or annotations in other languages, though their power is much, much greater.

Without further ado, let me provide a blueprint for this bridge across the semantic gap that I’ve been lamenting–the design guidelines for “marks.” Then I’m going to show you an example of how easy it could be to use marks, and how much power they give you.

image credit: Curious Expeditions (Flickr)

Blueprint

  1. Code and its compiler(s) must have a compile-time API specified by the language.
    It’s not okay if Clang generates one type of AST, GCC a second, and MSVC a third; all compilers that support the language must expose a spec-compatible, programmable API for all language constructs. For example, I need to be able to find out what parameters and local variables are declared in a function, and what their data types and other characteristics are. This is similar to what reflection offers, but reflection doesn’t help at all, because I need this before run-time. (Kudos to D, which provides compile-time reflection very similar to what I’m describing…) As I mentioned in my post about making a codebase const-correct, the lack of this feature is really a serious design flaw. Why should code, of all things programmers deal with, be impossible to code against?

Continue reading