[bitc-dev] DISCUSS: macros and surface syntax

[Jonathan S. Shapiro]

I'm going to come back to this with a more detailed message in a moment,
but I wanted to address this one specifically.

> Frustrated by lisp syntax, I looked for a way to get rid of
> parenthesis and I found the so-called Sweet Expressions, by David
> A.Wheeler  http://www.dwheeler.com/readable/     . There I came to
> know BitC and I thought "They're doing the greatest lisp of all
> time"  . Since Wheeler started the project right to give BitC a
> convenient way to display S-expressions, I wanted to ask if BitC devs
> kept in touch with him...

So first, I know and respect David Wheeler. We see each other a couple
of times a year, and I've been trying to get together with him for
dinner once in a while. Not as often as either of us (I suspect) might
prefer.

But I don't think sweet expressions are the answer for BitC. The idea is
quite clever, but I see two problems with it:

1. If you don't like S-expressions, sweet expressions don't go far
   enough to address your issues. As David notes quite clearly,
   resolving infix/prefix issues in expressions is actually very simple,
   and it is just as easy to do on the way *out* as on the way in. In
   fact, if you have a mixfix precedence table available, you really
   don't need the curly brace syntax at all.

   This means that infix/prefix/postfix operators in expressions are
   no impediment to a macro system. You simply pre-normalize those
   expressions to S-expressions before handing them to the macro system
   and then restore them to a more conventional format on the way out.
   All you have done here is escalate the syntactic "level" of a
   well-formed, pre-syntactic input a bit.

   What I'm really saying here is that expression operators actually
   aren't the problem, because there are so few syntactic patterns
   involved that you can do those transforms at the level of well-formed
   but pre-syntactic programs.

   The real issue is block structure. Note, in particular David's
   transform of (if e1 e2 3). He converts this into a block syntax
   without ever quite explaining why that conversion is valid. The
   answer is: because it's syntax. Which brings me to my point that
   any format more readable/usable requires that well-formed input
   and syntactically correct impact be more closely tied, and the
   closer that tie becomes the harder macro systems are to get right.
   In particular, one of the essential reasons to *have* macros is
   to be able to introduce new syntax...

2. BitC is still a moving target, and it has more syntax than is
   initially apparent. In fact, it has more syntax than it really
   ought to have. This isn't an argument against sweet expressions,
   but it makes the transform more subtle than you might think.

3. None of this addresses my more fundamental issue with macros, which
   is the complexity of having a compiler embed a full language
   interpreter.

shap