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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
