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]

Syntactic Sugar vs Syntactic Equivalence

a more stringent definition of Syntactic Sugar concept is syntactic equivalence. That is, the “sugar syntax” gets transformed into a canonical syntax by parser, before the compiler compiles the code.

This way, it's not merely sugar syntax, but syntax equivalence. Doesn't matter which syntax you use, they compile to the same output, 100% of the time.

WolframLang is like that. See WolframLang: Syntax, Operators Cheatsheet

Examples of Lose Sugar Syntax

for example, in C and C++, you have

They may not compile to the same thing.

in JavaScript ES2015 you have the 「class」 keyword. Like this:

class class_name { method1 method2 method3 … }

it is a “sugar syntax” in the sense that this class keyword is not necessary. However, 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.

[see JS: Class]

xtodo 2021-12-05 edit work in progress

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 (Magic Characters)] ))

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.))