6 ms·

> Lack of macro hygiene is just peachy keen among Scheme programmers as long as you are explicit about which identifier bindings can leak into, or out of, the m

> Lack of macro hygiene is just peachy keen among Scheme programmers as long as you are explicit about which identifier bindings can leak into, or out of, the macro definition from the macro call site. Not all Scheme programmers. Mostly Chicken users, in my experience :p The rest of us demand hygiene. > Scheme standards before R6RS[0] were a rough consensus on which language features everyone could agree on as useful additions. That's why only syntax-rules made the cut, not because Scheme programmers object to the ability to break hygiene. The reason only syntax-rules made the cut is precisely because the only thing the Scheme committee could come to a consensus on, as far as macros are concerned, was the high-level, hygienic syntax-rules system. In fact, the very reason Scheme didn't have a standard macro system for many years was specifically because of the problems of traditional procedural macros being unhygienic. > [0] R6RS, in a break from Scheme tradition, adopted a systemd-esque "come up with a standard for these needed features, any standard, and everybody else needs to fall in line whether or not they like it" approach. Err, no. R6RS adopted a 60% vote for the ratification of the standard rather than the 100% consensus approach used previously. This change was largely viewed as a welcome one by the community, because R5RS was delayed for nearly a decade because of one person (R. Kent Dybvig, iirc) holding out on some things everyone else wanted (especially records). Furthermore, the change to a vote was enacted by the Scheme community at large, and the editors of the R6RS were all well-known and respected members of the Scheme community before they assumed editorship. There's nothing systemd-esque nor "fall in line whether you like it or not" about it. The entire process was very democratic. The main reason R6RS hasn't seen wide adoption has more to do with its size than anything else. However, keep in mind that the Scheme Steering Committee had explicitly tasked the R6RS committee with creating a standard that was both backwards-compatible with IEEE Scheme and made it easier for Scheme implementations to be interoperable. At the time the R6RS process started, Scheme's biggest problem was determined to be the lack of portability available to Scheme programs due to the minimalism of R5RS, which made it inadequate for many real-world programs and lead to each implementation having its own incompatible extensions — as such, programs tended to run on one particular implementation and not any others. This made it especially difficult to write useful libraries for Scheme. While R6RS is far from perfect, the R6RS committee really did an admirable job in achieving that goal, all things considered.

qwertyuiop924 10y ago
>R6RS committee really did an admirable job in achieving that goal, all things considered. That's true. Although I didn't like the specific decisions they came to myself... >the problems of traditional procedural macros being unhygienic. But that wasn't even a problem by the time R5RS rolled around. syntactic closures had been around since 1988, and syntax-case had been around since 1992. R5RS released in 1998. 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. >Not all Scheme programmers. Mostly Chicken users, in my experience :p >The rest of us demand hygiene. That was a regrettable regression from CHICKEN 4, IMHO. I mean, we still have implicit renaming, which is hygienic, but ir is O(n). Frankly, Felix &co should have implemented syntactic closures. Or even syntax-case: as much as I dislike it personally (I agree with Shinn on this one), it's not badly designed, and it would be a heck of a lot better than what we got. But what can you do? 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?). But despite Andy Wingo's heroic efforts, Guile is still relatively slow, and Gambit has an even worse library selection than Guile's, which isn't that great (although, credit to the Guile devs, the apis on said libraries are really nice). I could bear the slowness, but the libraries...
- groovy2shoes 10y ago
  > 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 ;)

qwertyuiop924 10y ago

>R6RS committee really did an admirable job in achieving that goal, all things considered. That's true. Although I didn't like the specific decisions they came to myself... >the problems of traditional procedural macros being unhygienic. But that wasn't even a problem by the time R5RS rolled around. syntactic closures had been around since 1988, and syntax-case had been around since 1992. R5RS released in 1998. 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. >Not all Scheme programmers. Mostly Chicken users, in my experience :p >The rest of us demand hygiene. That was a regrettable regression from CHICKEN 4, IMHO. I mean, we still have implicit renaming, which is hygienic, but ir is O(n). Frankly, Felix &co should have implemented syntactic closures. Or even syntax-case: as much as I dislike it personally (I agree with Shinn on this one), it's not badly designed, and it would be a heck of a lot better than what we got. But what can you do? 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?). But despite Andy Wingo's heroic efforts, Guile is still relatively slow, and Gambit has an even worse library selection than Guile's, which isn't that great (although, credit to the Guile devs, the apis on said libraries are really nice). I could bear the slowness, but the libraries...

groovy2shoes 10y ago
> 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 ;)