Originally, I didn’t worry too much about programming language syntax. I think, starting out, I simply didn’t have enough exposure to the different options. Then as I started to really get interested in programming languages, my interest was focused on the semantics of different features. How they looked didn’t seem to make any difference when I had no idea what they actually did. Lisp and Forth were probably my first clue that syntax would be significant. And that makes sense because in those languages the syntax allows certain constructs to exist. However, I think that even if there does not exist any language construct that necessitates a specific syntax, the syntax of your language still has effects.
In Let Over Lambda [1], Doug Hoyte talks about “Duality of Syntax”. I’m not going to go into detail of this concept, but I believe he uses this principle in order to justify deviating from typical common lisp conventions as well as deciding on how to design new conventions. This is important because it’s setting up a theory on what makes good programs and then makes decisions in that framework.
You also see this (but sort of in the other direction) with Douglas Crockford’s Javascript the Good Parts [2]. And the punchline is something that I talked about in a previous blog post [3]. Normally, where you put a curly brace doesn’t really matter, but in javascript it does matter because semicolon insertion means that a return statement for an object literal might instead return ‘unknown’. Douglas’ solution is to say that in javascript you always put the open curly brace on the same line because that way you won’t run into the semicolon insertion problem. Here we’re using a syntax convention in order to avoid bad parts of the language, but my thought is that we should observe situations like what has occurred with javascript and instead create new languages that do not have these defects.
Also observe Jonathan Blow’s video series for the new programming language that he is developing [4]. Specifically try to keep an eye out for how he’s designing the syntax for functions. A locally defined function has nearly the exact syntax as a globally defined function; that’s on purpose. This design decision allows for a work flow that is much better optimized than if local and global functions have different syntaxes.
And finally take a look at my previous blog post [3] where I propose that we can decide what good syntax is by determining if it possesses certain mathematical properties that are advantageous.
Now I don’t think that there is going to be a ‘one syntax to rule them all’, but I do think that the reasoning behind our syntax and conventions needs to be based off of what properties we want our code to have. Just choosing an arbitrary set of rules for the sake of uniformity is missing the point (although it’s clearly on the right track). What we need is a careful analysis so that we can show in a very methodical fashion that our rules are helping us and not hindering us.
No comments:
Post a Comment