Sugar Syntax: Compiler Level vs User Level

By Xah Lee. Date: . Last updated: .

What is the Definition of Sugar Syntax?

try to define “sugar syntax” and not end up with turing machine equivalence. So, java python haskell are all sugar syntax of each other.

here's how Wikipedia defines it:

syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express.

Specifically, a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.

[Wikipedia 2016-11-27 Syntactic sugar]

indeed, so in that sense, you could say scripting languages such as ruby python are sugar syntax of C, Java.

Syntactic Sugar vs Syntactic Equivalence

a more stringent definition of “Syntactic Sugar” concept is “syntactic equivalence”. That is, you have 2 syntaxes in a language that are semantically equivalent 100%, compiles to the exact same machine code. e.g. Wolfram Language.

for example, in C like languages, you have i++. if that is syntactically equivalent to i = i + 1, in such way that the two expressions can be exchanged anywhere and does not effect the program a bit, not even efficiency, we say, they are syntactically equivalent. This is a true, good, “sugar syntax”.

for another example, in JavaScript ES2015, it's commonly said, the added Class keyword is just syntax sugar for its prototype system.

[see JS: Class]

actually, it's not, because, it's extremely complex and essentially impossible, to convert any code using class to another JavaScript source code such that the two have the exactly same semantics.

most programing languages define suger syntax at compiler level. Wolfram Language got it right. Suger syntax at user level. That's called meta-expr.

when you have it at compiler level, you get a profusion of syntax soup. In these languages, a suger syntax and its “original” syntax, usually are actually not semantically equivalent. Lots exceptions you have to dig out. Basically you are just creating syntax soup. (this includes, basically all langs: the if expression (test? yes:no) (aka ternary expression) vs if statement. Literal expression for array vs statements and declaration. Even lisp, haskell, clojure, are full of it. (lisp cons and dot notation, quote and apostrophe. [see Fundamental Problems of Lisp]. Clojure is full of it. [see Clojure: Function Chaining] [see Clojure Sigils Meaning] ))

When you have suger syntax at user level, programer apply a transformation and change the source code to whatever syntax they wish, by pressing a button in editor, or even programmably (without needing to write a parser, because the syntax transformation function is part of the language. It's pure syntactical transformation, no semantics involved. The “form” in “formal language”). In Mathematica, it's as simple as pressing a hot key. (while in stupid languages, a roughly similar idea is “lint” or “pretty print”, where you use a tool to change source code. And this tool has to be manually written from scratch. golang does best among these idiotic langs, by enforcing the use of this tool to unify source code formatting. (and python “solves” the problem by forcing into a irregular ah-hoc format-semantics, which prevent any sort of automatic rendering.))