> That's true. Although I didn't like the specific decisions they came to myself... Eh, I liked some, didn't like others. If I'd been knowledgeable enough at

> That's true. Although I didn't like the specific decisions they came to myself... Eh, I liked some, didn't like others. If I'd been knowledgeable enough at the time the ratification vote came around, I would've probably voted "no", but I also think I would've had only a few reservations (I was still a newb back then so I didn't vote). The rate of attrition during the drafting process was rather high, which leads me to suspect there were some politics going on internally among the editors, though I don't know for sure, but in retrospect it sure feels like some kind of foreshadowing. But, it's pretty much the same for R7RS-small: some things I like, others I don't. However, the few quibbles I have with R7RS-small are relatively minor (coincidentally, one of those quibbles has to do with parameters), so I cast a "yes". R7RS-large, though, is shaping up to be something I find really quite distasteful as a Schemer, possibly even moreso than R6RS. I may wind up abstaining regardless, as I've been working on my own Lisp dialect because I've grown kinda sick of the Scheme community in general (no offense — I just feel as though the disagreement and the in-fighting in the community will never end, and I'm tired of it), and after learning CL, EuLisp, ISLISP, and Le-Lisp, my ideas of what it means to "be Lisp" have changed a bit (not that I find Scheme bad in the least, quite the opposite, but I've developed an appreciation for the more traditional dialects, and I've discovered that my ideal is somewhere in the middle). Hell, if I were around for R5RS, I would've had some qualms even then (for example, I wouldn't have let it ratify until it had records — I would've let Dybvig filibuster until the end of time, and we'd still be using R4RS :p ). > The reason R5RS didn't have hygienic procedural macros was not because such a system hadn't been devised, ir was because the SSC couldn't agree on which one to use. Sure, but they did agree on syntax-rules. Furthermore, it wasn't clear at the time what the appropriate system to standardize was — turned out that ER macros can be implemented with synclos (and thus synclos are at least as powerful as ER macros), and synclos can be implemented with syntax-case (and thus syntax-case is at least as powerful as synclos), but nobody could figure out how to go in the reverse direction (and thus it's possible that syntax-case is strictly more powerful than synclos). There was hesitation to standardize a low-level macro system when it was possible that it was the "wrong" one (the point of having the low-level system in the first place was to provide something fundamental, and if synclos turned out to be strictly less powerful than syntax-case, they would not have been fundamental). To my knowledge, it's still an open question whether or not synclos can implement syntax-case. > we still have implicit renaming, which is hygienic, but ir is O(n). IR macros are my favorite low-level system by far. Their implementation in chicken (which I once ported to Chibi) is O(n) in the average case, but actually O(n^2) in the general case: since the macro walks the form to perform the renaming (twice!), you can theoretically wind up with lots of nested macro calls, in which case the expansion grows superlinear since it winds up walking both macro forms and their expansions. I spent a lot of time trying to come up with an implementation of IR macros in terms of synclos that didn't suffer from such problems but failed. I still think it's possible, but it might need a small change or addition to the synclo API. > Or even syntax-case: as much as I dislike it personally (I agree with Shinn on this one) I know we've had this discussion before, but please remind me why it is you don't like syntax-case. It's not perfect, but then again neither are ER macros or synclos. It essentially behaves like a mix of syntax-rules and IR macros, which is pretty much the ideal behavior in my opinion, but I'll be damned if its API isn't complicated. I think it's the right idea, but the interface is in dire need of simplification. (I do remember one objection was the introduction of new reader syntax, but that's really not essential to the system — we can discuss getting rid of it when we're coming up with that new API ;) ). > Gambit and Guile got this one right (well, they use syntax-case, but close enough), and debugging (which sucks in CHICKEN, even with Feathers, which is a massive improvement: I can't even evaluate arbitrary expressions on exception. Really?). Gambit's debugger is a dream. Is Guile's similar? I haven't used Guile much since 2.0, but that's going to change soon. > But despite Andy Wingo's heroic efforts, Guile is still relatively slow Yeah, Andy is amazing. He's done (and continues to do) great work on Guile. To be frank, Guile was a piece of shit until Andy took over, a laughable implementation at best. But since 2.0 it's been a serious contender, and 2.2 is shaping up to be a great release. > Gambit has an even worse library selection than Guile's Ugh, tell me about it. Marc tried to rectify that by introducing the snow package manager, but it never really took off. Shinn made a v2 of snow and included it with Chibi. I've got my fingers crossed that it gains traction this time. > I could bear the slowness, but the libraries... That feeling right there is what prompted R6RS to grow so much ;)