Short note on syntactic sugar
Bran Selic, during his #models13 tutorial on modeling language design, mentioned the notion of "syntactic sugar" in passing, and he sort of stated, as far as I understood, that he isn't too happy with the term, as it seems to belittle those constructs; they are certainly important presumably for those who want to benefit from these constructs, for as long as we assume that the constructs do indeed capture valuable domain concepts. (Sorry if I am getting him wrong.)
This got me thinking in that I wanted to hypothesize profoundly why this stuff is called "syntactic sugar". I was always assuming (and I think this is not controversial) that it simply classifies a language construct such that it can be eliminated from the language syntax by "desugaring", i.e., by a syntactic translation to core constructs.
Of course, people use the term syntactic sugar in a somewhat more flexible manner. That is, they may also use it for constructs that do require a bit more effort such as some sort of type analysis. This is a slippery slope. Whether or not such extra analysis is needed may also depend on quite technical details regarding type system and semantics.
What I find slightly more interesting here is the fact that the term is maybe usefully deployed in technical discussions among language engineers, but the question arises why the term should leak into the pragmatics or overall end-user picture of the language. This is happens, for example, in much communication aiming at teaching programming languages.
The end user is certainly not meant to fully appreciate the term for as long as the simple, macro-like nature (or feasibility) of these constructs is not transparent to the end user. Arguably, it is useful though for the end user to understand quickly that a given construct is not yet another major concept, but it rather is a simple pattern for using existing constructs.
Thus, better term sought after.
Ralf
This got me thinking in that I wanted to hypothesize profoundly why this stuff is called "syntactic sugar". I was always assuming (and I think this is not controversial) that it simply classifies a language construct such that it can be eliminated from the language syntax by "desugaring", i.e., by a syntactic translation to core constructs.
Of course, people use the term syntactic sugar in a somewhat more flexible manner. That is, they may also use it for constructs that do require a bit more effort such as some sort of type analysis. This is a slippery slope. Whether or not such extra analysis is needed may also depend on quite technical details regarding type system and semantics.
What I find slightly more interesting here is the fact that the term is maybe usefully deployed in technical discussions among language engineers, but the question arises why the term should leak into the pragmatics or overall end-user picture of the language. This is happens, for example, in much communication aiming at teaching programming languages.
The end user is certainly not meant to fully appreciate the term for as long as the simple, macro-like nature (or feasibility) of these constructs is not transparent to the end user. Arguably, it is useful though for the end user to understand quickly that a given construct is not yet another major concept, but it rather is a simple pattern for using existing constructs.
Thus, better term sought after.
Ralf
My objection to the term is that it reflects an attitude, common among programmers, that concrete syntax is for wimps; i.e., that it is not really important. My view is that this is not only wrong, but actually damaging. Understanding software is a hard enough task that anything we can do to help readers is a good thing. The concrete syntax is the primary interface through which we understand a program.
ReplyDelete