I agree with Meng.
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.
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.
Meng, I wasn't aware of this "riaxpander", it seems chicken also has it. Is your riaxpander implementation open source?
I would add these comments to the original post:
- 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:
- 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.
- 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.
- Generics are defined in several libraries, there are many implementations.
- 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.
Thanks to everyone for your comments.
Best regards