<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div>Thank you Pascal for your comments, very informative and enlightening.<br><br>Alexandre <br><div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On 24 Nov 2018, at 14:10, Pascal Costanza <<a href="mailto:pc@p-cos.net">pc@p-cos.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">Hi,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 24 Nov 2018, at 15:14, Alexandre Rademaker <<a href="mailto:arademaker@gmail.com" class="">arademaker@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div>In the LoL book we learn the flexibility of the Common Lisp macro system. Reading now <div class=""><br class=""></div><div class=""><a href="http://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html" class="">http://blog.racket-lang.org/2011/04/writing-syntax-case-macros.html</a></div><div class=""><br class=""></div><div class="">It seems that the Racket macros do not necessarily impose constraints to the programmers. But I never really used it. Does anyone here have experiences with both approaches, sufficient to give insights about the good and bad of each one? <br class=""></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">syntax-case is, strictly speaking, strictly more expressive than Common Lisp macros. If it is worth it to switch to syntax-case because of this, is a different question though, because you can make an argument that the increase in expressiveness doesn’t solve an essential problem.</div><div class=""><br class=""></div><div class="">syntax-case solves a particular case of macro hygiene issues. (syntax-rules solves it too, but removes a lot of other possibilities to express things, whereas syntax-case doesn’t have such restrictions.)</div><div class=""><br class=""></div><div class="">The problem can be illustrated with a simple example:</div><div class=""><br class=""></div><div class="">(defun foo ()</div><div class=""> (let ((x 42))</div><div class=""> (macrolet ((bar () ‘x))</div><div class=""> (let ((x 4711))</div><div class=""> (bar)))))</div><div class=""><br class=""></div><div class="">It can be argued, especially if you’re a very strong believer that everything should be lexically scoped without exception, that (foo) should return 42, because the bar macro apparently refers to the variable named x bound to 42. Alas, (foo) actually returns 4711, and Common Lisp provides no way to solve this /in the language/. (That last part, “in the language”, is very important when speaking of expressiveness. There are very good pragmatic solutions to this issue which, however, only work by convention and are not based on explicit language mechanisms. My favorite solution is to just use different names for the different bindings. ;)</div><div class=""><br class=""></div><div class="">With syntax-case and its default notations, which look very different from the Common Lisp macro system, (foo) would by default return 42, but there are mechanisms in syntax-case to also return 4711 if you explicitly ask for it, without renaming any of the variables.</div><div class=""><br class=""></div><div class="">There is a very interesting paper by Daniel Friedman called “Object-Oriented Style” - see <a href="https://www.cs.indiana.edu/~dfried/" class="">https://www.cs.indiana.edu/~dfried/</a> - where he implements an object system completely in syntax-case (that is, without the need for any particular runtime support), and where a variant of this issue pops up. I found it very enlightening to try to reimplement this with Common Lisp’s macro system, because you can actually get very far with it. (There are some tricks using &env-based environment objects, macroexpand with explicit passing of such environment objects, and symbol-macrolet, but you will ultimately arrive at a stumbling block where this doesn’t work anymore.)</div><div class=""><br class=""></div><div class="">This paper motivated me to actually embed hygienic macros in Common Lisp. This is described in <a href="http://www.jucs.org/jucs_16_2/embedding_hygiene_compatible_macros" class="">http://www.jucs.org/jucs_16_2/embedding_hygiene_compatible_macros</a></div><div class=""><br class=""></div><div class="">However, this is not a solution “in the language” because this only works reliably if you write your whole programs in that system.</div><div class=""><br class=""></div><div class="">I’m still not convinced that hygienic macro systems like syntax-case are worth the complexity. Again, just don’t reuse variable names, and you should be fine. (For global variables, it’s easy to use the Common Lisp package system to solve hygiene issues.)</div><div class=""><br class=""></div><div class="">Just my 0.02€.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pascal</div><div class=""><br class=""></div><div class="">
--<br class="">Pascal Costanza<br class=""><br class="">
</div>
<br class=""></div></blockquote></body></html>