

Desugaring as a Language Feature - gus_massa
http://cs.brown.edu/courses/cs173/2012/book/Desugaring_as_a_Language_Feature.html

======
PeterisP
How about sugaring as a language feature?

What I mean is that if the language has multiple ways to express statements
that are semantically absolutely identical but differ in just the 'sugar',
then it would be useful to have a way to automatically 'normalize' the code to
always use a single idiomatic way of doing it (which in many languages is the
'sugar' version).

It's just like with indentation and brace styles - the original authors may
each have their own preferences, but when reading code, it's more efficient to
view the code in a single style according to my preferences, and that can be
done automatically by showing me the code as reindented, with my preferred
brace positioning, my habitual syntax highlighting color scheme ... and also
with a standartized level of sugaring.

~~~
shriramkmurthi
If you have a way of automatically detecting that two terms in a program are
semantically identical, don't keep it secret! [Hint: Halting Problem.]

~~~
alloyed
That's not how I read gp, exactly. What he is saying sounds more like taking
the AST of a program, desugaring at much as possible, and then re-sugaring it
in such a way as to produce a consistently styled codebase, sort of like gofmt
but more opinionated and linter-like.

~~~
shriramkmurthi
What he wrote is "statements that are semantically absolutely identical but
differ in just the 'sugar'". I was just quoting him back. Of course, one can
always construct various hacky approximations to this, and maybe that's what
he intended, even if it isn't what he wrote; I couldn't possibly tell.

~~~
JadeNB
I think that this is (quite) a bit like claiming (verified) compiler
optimisations are impossible because they, too, have to re-write any given
expression only to a semantically identical one. One wants to detect _only_
pairs of statements that are semantically identical; this does not require
detecting _all_ such pairs.

~~~
shriramkmurthi
Look, the OP could have been precise. We have terminology that makes all these
things very exact. That's why terms like "soundness", "completeness", etc.
were invented.

The OP wrote something that is ambiguous. I was pointing out why it's tricky.
You're welcome to interpret it in a way that makes it less tricky.

However, what you're asking for still requires a pretty strong decision
procedure if you want something that is actually of use on non-trivial
examples. If you have expressions that are nested, then you need to be able to
reason about all possible contexts; if you have state, you need to reason
about all possible states. Maybe you have lots of experience with this kind of
reasoning and have gotten used to it, but I find the necessary underlying
proofs (whether human or automated) pretty heavy going.

------
shriramkmurthi
For more detail, I suggest reading chapters 35, 36, and 37 of the first
edition of this book (PLAI), which provide even more detail. See
[http://www.plai.org/](http://www.plai.org/).

------
6cxs2hd6
There are quite a few introductions to macros. Maybe like monads, it's a topic
where people need to read a few until one "clicks" for them.

Having said that, I think this is among the best. The writing style is
friendly, the examples are meaningful, and it builds up in digestible steps.

