The difference between “Syntax” and “Syntactic Sugar”

compilersyntaxterminology

Background

The Wikipedia page on Syntactic Sugar states:

In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for humans to use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer.

I don't really understand what the difference is between Syntactic Sugar and Syntax.

I appreciate the point that the sugary version can be clearer, more concise, perhaps boil off some boilerplate. But I feel at some level, all the syntax is essentially doing that to form an abstraction over what the code gets compiled down to.

From the same Wikipedia page:

Language processors, including compilers, static analyzers, and the like, often expand sugared constructs into more fundamental constructs before processing, a process sometimes called "desugaring".

As a thought exercise, if I take "often" in this statement to mean "always": If the difference were just whether the compiler "desugars" the syntax before moving to a next stage, how might a coder who does not know the innards of the compiler know (or care) what is Sugar'd Syntax or not?

A very much related question on this site "Rigorous Definition of Syntactic Sugar?" has an answer which commences:

IMHO I don't think you can have a definition for syntactic sugar, because the phrase is BS and is likely to be used by people that talk about "real programmers" using "real tools" on "real operating systems"

Which might indicate to me that perhaps there isn't a huge difference to the coder using the language?
Perhaps the difference is only perceptible to the compiler writer? Though there may be instances in which it's helpful for the coder using the language to know what's under the hood of the Syntactic Sugar? (But perhaps in reality any discourse on the subject tends to use the term as flame bait?)

The heart of the question

So… the short version of the question:

Is there a real difference between Syntax and Syntactic Sugar?
Who does it matter to?

Extra Food for Thought

Bonus on topic contradiction:

On the Wikipedia page an example is given:

For instance, in the C language the a[i] notation is syntactic sugar for *(a + i)

Whereas another answer on the above linked question talks about the same example:

Now consider a[i] == *(a + i). Think about any C program that uses arrays in any substantive way.

And summarizes that:

The [] notation facilitates this abstraction. It's not syntactic sugar.

The opposite conclusion for the same example!

Best Answer

The main difference is that syntax is grammar defined in a language to allow you to expose some functionality. As soon as you could get to that functionality, any other syntax that lets you do the same thing is considered sugar. That of course runs into odd scenarios about which of the two syntaxes is the sugar, especially since it's not always clear which came first.

In practice, syntactic sugar is only used to describe syntax added to a language to facilitate ease of use, like making infix lhs + rhs map to lhs.Add(rhs). I would consider C's array indexing to be syntactic sugar.

It matters mostly because elegant designs tend to limit the amount of duplication. Needing (or at least wanting) syntactic sugar is seen by some as a sign of a design failing.

Related Solutions

How to view Scala code without all the syntactic sugar

You can use -print when compiling Scala, and it will print a de-sugared version of the code. Unfortunately, you'll see that Scala has syntactic sugar for good reason.

Let's see a very simple example:

object T {
  def first[A : Ordering](l: List[A]): A = {
    val s = l.sorted
    s(0)
  }
}

And the output:

package <empty> {
  final object T extends java.lang.Object with ScalaObject {
    def first(l: List, evidence$1: scala.math.Ordering): java.lang.Object = {
      val s: List = l.sorted(evidence$1).$asInstanceOf[List]();
      s.apply(0)
    };
    def this(): object T = {
      T.super.this();
      ()
    }
  }
}

You'll often see things like <empty> -- these are compiler annotations, not valid Scala code. For example, a parameter in a case class will have its getter tagged with <stable> <caseaccessor> <accessor> <paramaccessor>. Also, a case class will have a number of methods marked <synthetic>, to indicate they were created by the compiler.

Also, the this constructor you see here is not valid Scala code, exactly. In this case, the "normal" Scala constructor (which is the body of the class, trait or object) is moved inside such a this method -- which is how Java itself sees things.

So, this is mixture of Scala and Java, with a bit of compiler internals sprinkled over it. But it will show the de-sugared stuff.

Syntax vs. Semantics – What’s the Difference?

Semantics ~ Meaning

Syntax ~ Symbolic representation

So two programs written in different languages could do the same thing (semantics) but the symbols used to write the program would be different (syntax).

A compiler will check your syntax for you (compile-time errors), and derive the semantics from the language rules (mapping the syntax to machine instructions say), but won't find all the semantic errors (run-time errors, e.g. calculating the wrong result because the code says add 1 instead of add 2).