Neil Toronto: > That was totally awesome. Ha ha! I actually understand what macros are > now! In fact, I want them in Python... > I can see how they'd be difficult to do properly with a conventional > procedural language. Would they be hard to do with sweet-exprs?
Well, that's one of my primary goals with sweet-expr's, to create an easier-to-read language that RETAINS macros and Lisp's other advantages. As you can see, that's harder than it looks. Which is why there has been a large litter of failed attempts to create Lisp-like languages with "nicer" syntax. But I think I've identified why the previous ones failed, and that is the first step to succeeding where others have not. Most of the old efforts failed because: 1. They had many rules specific to their specific underlying s-expression system. When the rules changed, their surface syntax couldn't trivially adapt. 2. It was hard to see the mapping between their surface form and the underlying s-expression, so macros became impossible to understand/debug. You can have macros and a different surface syntax, no problem. Just have the reader transform the surface syntax into an s-expression. Macros normally operate on s-expressions, so as long as you transform it to an s-expression first, they work just fine. But if the difference between the surface syntax and the s-expression is too great, then you can't reasonably DEBUG a macro when things go wrong, and they're way more likely to go wrong, too. So in this message: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html He gives a Lisp macro example: (defmacro set-sqrt (place v) `(setf ,place (* v v))) (defsetf sqrt set-sqrt) Let's express that in sweet-expressions (current version): defmacro set-sqrt place(v) `setf(,place (v * v)) defsetf sqrt set-sqrt If I switched to using {...} for grouping it'd be almost the same: defmacro set-sqrt place(v) `setf(,place {v * v}) defsetf sqrt set-sqrt Notice that UNLIKE nearly ALL "easy" surface syntaxes, like M-expressions, sweet-expressions are carefully designed so you can ALWAYS find, automatically, the "end" of the expression. That's something that typical formats don't give you. Alan Manuel Gloria: > >>> Finally - conventional wisdom claims that LISP's most important power, > >>> macros, is possible only because of the sheer number of parens in the > >>> s-expr syntax (I would contend this, though). I agree with you (i.e., I'd contend it). This claim by others is best refuted by example, and look, there's one above! --- David A. Wheeler