<div dir="ltr">I agree with Meng.<div style>I see syntax-rules as a DSL for hygienic macros. It is completely "schemey" in the same way libraries like Kanren for logic programming, or FrTime for reactive programming are. The only difference is that when using hygienic macros, your code becomes data as well, to be processed before it actually turns into code.</div>

<div style>Actually, when you take into account a couple of pitfalls regarding lexical scoping and shadowing and use a variety of techniques, including continuation-passing-style, writing syntax-rules macros are extremely powerful and similar to regular recursive scheme. Unhigienic macros are well-known timebombs that are waiting to explode as soon as client code does something the library didn't think of. They are useful for self-sufficient systems, as Mikael said.</div>

<div style><br></div><div style>Meng, I wasn't aware of this "riaxpander", it seems chicken also has it. Is your riaxpander implementation open source?</div><div style><br></div><div style>I would add these comments to the original post:</div>

<div style><br></div><div style>- CAR and CDR are shorter than FIRST and REST (why not HEAD-TAIL?), so besides the historical meaning, I prefer them for this reason. However, you can always define your own first and rest (the former is actually defined in SRFI-1). About making them generic, next point:</div>

<div style>- I think the procedure specialization for types (char=, *-lenght, etc...) is good as it favors performance. If you want the generic ones, it is straightforward to define. For instance, that's what the author of SRFI-47 does: replace array=? with an array-augmented version of R5RS equal?. While you can do your own specialization, you couldn't do it the other way around: given a generic procedure in R5RS, specialize it for your types.</div>

<div style>- Mikael's point about symmetry is absolutely beautiful. And indeed I defend the usefulness of values, which are of special interest in functional programming where you avoid side-effects. Also, the points about C/C++ (and assembly I may add) are completely true, but that's one of the reasons I find Gambit a particularly powerful system.</div>

<div style>- Generics are defined in several libraries, there are many implementations.</div><div style>- Promise and force are re-defined in R5RS terms in SRFI-45. I agree with this point, but I don't know the deeper reasons why they are included, because even opening the possibility to  implementations-defined optimized representation of this primitives could have been done with an SRFI.</div>

<div style><br></div><div style>Thanks to everyone for your comments.</div><div style><br></div><div style>Best regards</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 5, 2013 at 1:16 PM, Meng Zhang <span dir="ltr"><<a href="mailto:wsxiaoys.lh@gmail.com" target="_blank">wsxiaoys.lh@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Great post Mikael! So happy to read your thoughts.</div><div class="im"><div class="gmail_extra">

<br><div class="gmail_quote">On Sat, Jan 5, 2013 at 6:37 PM, Mikael <span dir="ltr"><<a href="mailto:mikael.rcv@gmail.com" target="_blank">mikael.rcv@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>The syntactic-closures based macro systems (syntax-rules/syntax case including define-syntax, syntax-rules, let-syntax, letrec-syntax) bring incredible complexity and with that low debuggability through a very complex identifier concept based a kind of duality of the identifier symbol in itself and the syntactic environment in which it is used in a particular instance, and brings a complex API for handling macros with this, that by nature is not Schemy and not suited for debugging.</div>




<div><br></div><div>Per came with the suggestions above based on having spent approx 6 months fulltime on developing the Black Hole module system, which does hybrid define-macro and syntactic closures expansion.</div><div>




<br></div><div>There might be some caveat I didn't get, but, I'd guess you could actually make a macro expander that supports both an alias macro system as per above and a syntactic-closures for compatibility with code that uses it, possibly by splitting expansion into two expansion phases, thus isolating all the identifier-related complexity.</div>




<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"></blockquote></blockquote></div><br></div>


</div><div class="gmail_extra">While talking about the syntactic-closures, If we ignore syntax-case, I'll disagree that it brings "incredible" complexity. I've been uncertain</div><div class="gmail_extra">


on syntactic-closures for years, while this Holiday I finally got spare time reading its implementation in riaxpander/chibi-scheme, I found</div><div class="gmail_extra">the concept of it is quite straight forward. Though I deadly missed an easy-to-understand, concrete implementation with document for it during</div>


<div class="gmail_extra">the learning process.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I've cloned such a system in gambit, and keep digging on how to integrate hygiene with module system and gambit's compiling process.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">Meng</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>

<div class="gmail_extra">
<br></div></font></span></div>
<br>_______________________________________________<br>
Gambit-list mailing list<br>
<a href="mailto:Gambit-list@iro.umontreal.ca">Gambit-list@iro.umontreal.ca</a><br>
<a href="https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list" target="_blank">https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list</a><br>
<br></blockquote></div><br></div>