Thanks for the feedback.  I appreciate it.  I think I'd like to narrow my focus to the primary thing, which was the lack of generality of the built-in procedures, and generics.

Making these efficient to compile (especially with a module system) seems hard, but rewarding.  I'm thinking about how to do this more.  Personally, I don't think efficiency in terms of constant factors should often win versus code which could be more general.   Clearly this is a value choice; however, I wonder how well a compiler can eliminate type dispatching without adding type annotation to the language.

So, I'm thinking about these things and will let them stew for... another 10 years?  I don't know.

Thanks,
-Jason



On Sun, Jan 6, 2013 at 5:38 AM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com> wrote:
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



On Sat, Jan 5, 2013 at 1:16 PM, Meng Zhang <wsxiaoys.lh@gmail.com> wrote:
Great post Mikael! So happy to read your thoughts.

On Sat, Jan 5, 2013 at 6:37 PM, Mikael <mikael.rcv@gmail.com> wrote:

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.

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.

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.


While talking about the syntactic-closures, If we ignore syntax-case, I'll disagree that it brings "incredible" complexity. I've been uncertain
on syntactic-closures for years, while this Holiday I finally got spare time reading its implementation in riaxpander/chibi-scheme, I found
the concept of it is quite straight forward. Though I deadly missed an easy-to-understand, concrete implementation with document for it during
the learning process.

I've cloned such a system in gambit, and keep digging on how to integrate hygiene with module system and gambit's compiling process.

Thanks
Meng




_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list



_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list