Syntax Design

One of the most recognizable features of a languages is its syntax. What are some of the things about syntax that matter?

Bracketing

At some point in the history of programming languages, the idea of code as lists of statements with jumps or gotos gave way to the idea of nested (hierarchical) declarations and control structures, as in this abstract syntax tree:

ast.png

Aha, so programs are really trees! But we still need a string representation for storage and transmission. How can we capture trees in text? There are two main approaches. The first is to just give a direct representation of the syntax tree. The other is to be creative with syntax, making something that a human might possibly like to read.

Let’s play around with different sketches of representations of the above tree.

S-Expressions

The usual direct representation of trees in strings is that of S-expressions—parenthesized forms such as (A B C D) where A is the root and B, C, and D are A’s (ordered) children. The children can be primitive values or even...wait for it...trees.

(function f (params x y)
    (block
        (var b 3)
        (if (< x (* a (+ b 7)))
            (while found
                (block
                    (for i (range 2 5) (print i))
                    (if (== a 2) (break))))
            (= p (cos 5)))
        (return (/ a 5))))

Beautiful, right? Well-loved languages like LISP, Racket, and Clojure use S-expressions (though with a few little extensions here and there).

Now notice that in the example above, some of the objects aren’t actually evaluated. We’re seeing the distinction between symbols and value expressions. Can we make this explicit in the syntax? Yes we can:

(function :f (params :x :y)
    (block
        (var :b 3)
        (if (< x (* a (+ b 7)))
            (while found
                (block
                    (for :i (range 2 5) (print i))
                    (if (== a 2) (break))))
            (= p (cos 5)))
        (return (/ a 5))))

Here :x means just “the symbol x.” It’s just a symbol, nothing more, nothing less. On the other hand, x is an expression that means “go look up the value associated with the symbol :x an use this value.”

That is a pretty huge difference, isn’t it?

Exercise: Explain this difference to your neighbor.

XML Style

The tree can be given directly in XML, too. This is ridiculously verbose, not only because we have some markup characters, but because we have to invent elements for leaf nodes. Why are we looking at this? Pretty much just to show it’s possible to show hierarchical structures as strings in more than one way.

Please do not do anything like this.

<function name="f" params="x,y">
  <block>
    <var id="b"><intlit value="3"/></var>
    <if>
      <less>
        <ref id="x"/>
        <times>
          <ref id="a"/>
          <plus><ref id="b"/><intlit value="7"></plus>
        </times>
      </less>
      <while>
        <ref id="found"/>
        <block>
          <for var="i">
            <range><intlit value="2"/><intlit value="5"/></range>
            <print><ref id="i"/></print>
          </for>
          <if>
            <eq><ref id="a"/><intlit value="2"/></eq>
            <break/>
          </if>
        </block>
      </while>
      <assign>
        <ref id="p"/>
        <cos><intlit value="5"/></cos>
      </assign>
    </if>
    <return>5</return>
  </block>
</function>

JSON Style

Another form of direct tree representation is an encoding in JSON. This gets pretty verbose as well because in JSON the properties are unordered, so naming them seems to be the most reasonable approach. And we pretty much have to name everything:

{type: "function", name: "f", params: ["x", "y"], body: {
    type: "block", statements: [
        {type: "var", id: "b", init: 3},
        {type: "if",
            condition: {type: "<", left: "x", right: {
                type: "*",
                left: "a",
                right: {type: "+", left: "b", right: 7}
            }},
            truePart: {type: "while",
                condition: "found", body: {type: "block", statements: [
                    {type: "for", var: "i",
                        range: {type: "range", low: 2, high: 5},
                        body: {type: "print", args: ["i"]}
                    },
                    {type: "if",
                        condition: {type: "==", left: "a", right: 2},
                        truePart: {type: "break"}
                    }
                ]}
            },
            falsePart: {type: "assign",
                target: "p",
                source: {type: "cos", args: [5]}
            }
        },
        {type: "return", value: 5}
    ]
}}

Indentation

Okay, let’s move away from direct representations and use some “real syntax.” By real syntax we mean creatively arranging symbols in a pleasing and readable way but still having it be possible to unambiguously recapture the tree structure.

function f (x, y)
    var b = 3
    if x < a * (b + 7)
        while found
            for i in 2..5
                print i
            if a == 2
                break
    else
        p = cos(5)
    return a / 5

Curly Braces

The use of curly braces to define subtrees is, for some reason, very popular.

function f (x) {
    var b = 3;
    if (x < a * (b + 7)) {
        while (found) {
            for (i in 2..5) {
                print i;
            }
            if (a == 2) {
                break;
            }
        }
    } else {
        p = cos(5);
    }
    return a / 5;
}

Terminating Keywords

Rather than marking the beginning and end of a block, as is done with the curly brace style and its equivalents, we can get away with just marking the end. It’s true! This can be done simply with the word end:

function f (x, y)
    var b = 3
    if x < a * (b + 7)
        while found
            for i in 2..5
                print i
            end
            if a == 2
                break
            end
        end
    else
        p = cos(5)
    end
    return a / 5
end

or by spelling the initial word backwards (yes, many languages do this):

function f (x, y)
    var b = 3
    if x < a * (b + 7)
        while found
            for i in 2..5
                print i
            rof
            if a == 2
                break
            fi
        elihw
    else
        p = cos(5)
    fi
    return a / 5
noitcnuf

Postfix Style

A postfix style representation allows pretty simple evaluation on a stack machine. Here it’s crucial to distinguish symbols from variables—it’s pretty hard (impossible in general?) to distinguish a defining occurrence of an identifier from a using occurrence. We sometimes have to bundle code blocks; here I used square brackets for that purpose:

[ :x param :y param ]
[
    3 :b var
    x a b 7 + * <
    [
        found
        [
            :i 2 5 [i print] for
            2 a == [break] [] if
        ]
    while]
    [5 cos p assign]
    if
    a 5 / return
] :f function

Functional Style, with let and Infix Operators

Here’s a style that borrows from Standard ML. Block scope is introduced with the let...in...end expression, and expression sequences use semicolons as separators. Expression sequences are allowed in the body of a let, or wherever any old expression can go, provided the sequence is enclosed in parentheses.

function f (x, y) =
    let
        b = 3
    in
        if x < a * (b + 7) then
            while found do (
                for i in 2..5
                    print i
                ;
                if a == 2 then
                    break
                else
                    nil
            )
        else
            p = cos(5)
        ;
        a / 5
    end

Delimiters

How to separate one construct from another is a really big issue in syntax design, believe it or not. We can identify two main classes of languages: those in which newlines are significant and those in which they are not.

“Insignificant” Newlines

In many languages, newlines are just like any other whitespace character (except for minor exceptions such as single-line comments and single-line string literals. Then, unless you have an S-Expression-based syntax as in LISP, Scheme, and Clojure, you’ll need semicolons to terminate (or separate) statements. This means you can (but shouldn’t) write code like:

#define ZERO 0
    unsigned  gcd(   unsigned   int  // Euclid's algorithm
      x,unsigned   y) {   while ( /* hello */  x>   ZERO
   ){unsigned temp=x;x=y   %x;y  = temp ;}return

   y ;}

“Significant” Newlines

Where you place your newlines matters greatly in, let’s see, Assembly languages, Python, Ruby, JavaScript, CoffeeScript, Elm, Haskell, Go, Swift, and yes, many others. The rules can get pretty technical.

Python scripts are defined as sequences of logical lines, delimited by the token NEWLINE. A statement may not cross logical lines, except in the case of compound statements in which each constituent simple statement ends with a NEWLINE. Logical lines are made up of one or more physical lines according to line joining rules. Lines are implicitly jointed within parentheses, brackets, or braces; lines can be explicitly joined by ending with a backslash. These rules are somewhat exclusive of comments and string literals.

Ruby looks at the end of each line and says “well if up to here it looks like we’ve completed a statement the we have.” This means you have to be careful where you break lines:

puts 5
  + 3
puts 5 +
  3

prints 5 then 8.

Exercise: Why?

“Possibly Significant” Newlines

JavaScript requires most statements to be terminated by semicolons, but the compiler will put one in for you if it looks like you might have missed one. The rules by which this implicit semicolon insertion is done have to be learned and they might be hard to remember, so some people give the advice to always put them in at the end of every statement that requires them.

Exercise: Research the infamous Implicit Semicolon of JavaScript. Which statements are supposed to be terminated by a semicolon? When is a semicolon inserted? Give four examples of how writing JavaScript in a "free-form" manner is impossible because of semicolon insertion.

Not everyone agrees that you should always put semicolons in:

zzzzing.png

Syntactic Sugar

Syntactic sugar refers to forms in a language that make certain things easier to express, but can be considered surface translations of more basic forms.

This is best understood by example. There are zillions of examples out there. Here are a few. (Disclaimer: Some of these are just examples I made up and are not part of any real language.)

ConstructDesugared FormDescription
x += nx = x + nCompound assignment
a + boperator+(a, b) or
"+"(a, b) or
__add__(a, b)
Common in languages that allow overloading
a[i]*(a + i)(C, C++) Because C does not have real arrays
p -> x(*p).x(C, C++) Field of struct being pointed to
ff()Some languages let you leave off parentheses in calls with no arguments
f xf(x) or
x.f()
Some languages let you leave off parentheses in calls with one argument
x op yop(x, y) or
x.op(y)
Some languages let you leave off parentheses in calls with two arguments
r = [s for x in a if e]r = []
for x in a:
  if e:
    r.add(s)
List comprehension
x orelse yif x then true else y(Standard ML) short-circuit disjunction
x andalso yif x then y else false(Standard ML) short-circuit conjunction
[x, y, z]x :: y :: z :: nilLists in Standard ML
"a${x}b""a" + x + "b"String interpolation
Exercise: Find some more examples.

When the sugared form is completely gratuitous or actually makes the code less readable, you sometimes hear the term syntactic syrup or syntactic saccharin.

Syntactic Salt

Here’s the definition from The New Hacker’s Dictionary:

The opposite of syntactic sugar, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what’s going on, rather than to express a program action. Some programmers consider required type declarations to be syntactic salt. A requirement to write “end if”, “end while”, “end do”, etc. to terminate the last block controlled by a control construct (as opposed to just “end”) would definitely be syntactic salt. Syntactic salt is like the real thing in that it tends to raise hackers’ blood pressures in an unhealthy way.

Compactness and Verbosity

Some people love a very verbose syntax, where you say everything, because explicit is better than implicit. Some people love very terse syntax, as there is less cognitive load and less noise in the code. Please be reasonable, though. There is such a thing as code that is too terse, and such a thing as code that is too verbose.

Terseness

Some languages pride themselves on doing a whole lot with few characters:

An example from Ruby (do you see what this does?):

c = Hash.new 0
ARGF.each {|l| l.scan(/[A-Z']+/i).map {|w| c[w.downcase] += 1}}
c.keys.sort.each {|w| puts "#{w}, #{c[w]}"}

An example from APL (The 99 bottles of beer program taken from Rosetta Code):

bob  ←  { (⍕⍵), ' bottle', (1=⍵)↓'s of beer'}
bobw ←  {(bob ⍵) , ' on the wall'}
beer ←  { (bobw ⍵) , ', ', (bob ⍵) , '; take one down and pass it around, ', bobw ⍵-1}
↑beer¨ ⌽(1-⎕IO)+⍳99

Here’s APL again, with an expression to find all the prime numbers up to R:

(~R∊R∘.×R)/R←1↓⍳R

Candygrammars

Somtimes you will encounter languages that tend to look like a natrual language. What do you think about this?

An example in Hypertalk (taken from Wikipedia):

on mouseDown
   answer file "Please select a text file to open."
   if it is empty then exit mouseDown
   put it into filePath
   if there is a file filePath then
     open file filePath
     read from file filePath until return
     put it into cd fld "some field"
     close file filePath
     set the textStyle of character 1 to 10 of card field "some field" to bold
   end if
 end mouseDown
 

An example from Manatee:

to get the truth value prime of whole number n:
    return no if n < 2
    for each d in 3 to n - 1 by 2:
        return no if d divides n
    end
    return yes
end
for each k in 1 to 100:
    write k if prime(k)
end

In practice this kind of verbosity is worse than it sounds. Here’s what the New Hacker’s Dictionary has to say about this:

candygrammar /n./ A programming-language grammar that is mostly syntactic sugar; the term is also a play on “candygram.” COBOL, Apple’s Hypertalk language, and a lot of the so-called “4GL” database languages share this property. The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program. This intention comes to grief on the reality that syntax isn’t what makes programming hard; it’s the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that candygrammar languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker.

[The overtones from the old Chevy Chase skit on Saturday Night Live should not be overlooked. This was a "Jaws" parody. Someone lurking outside an apartment door tries all kinds of bogus ways to get the occupant to open up, while ominous music plays in the background. The last attempt is a half-hearted "Candygram!" When the door is opened, a shark bursts in and chomps the poor occupant. There is a moral here for those attracted to candygrammars.]