3 ms·
> Neat. But er IS actually hygenic by the standard definition. It's hygienic in that it allows you to write any hygienic macro, yes. However, it's not "hygien
by groovy2shoes 10y ago
> Neat. But er IS actually hygenic by the standard definition.
It's hygienic in that it allows you to write any hygienic macro, yes. However, it's not "hygienic by default" -- you have to go out of your way to manually and explicitly ensure your er-macros are hygienic. Leave out a ,(rename 'foo) somewhere, and suddenly you've broken hygiene. Same problem with gensym, really, except that rename is a little nicer to use. Compare with syntax-rules, syntax-case, or ir-macros, where any macro you write is hygienic automatically and by default -- you have to go out of your way to manually and explicitly inject free identifiers.
> I'd say I'd check out what Eli &co did, but I probably won't. TBH, Racket leaves a bad taste in my mouth: the core is too complex for such little benefit.
It's also a proposed addition for R7RS-large (SRFI-139).
> If some of it were in libraries, I wouldn't mind so much, but most of it's there by default.
It's all in libraries. `#lang racket` is just a "metalibrary" that exports a bunch of smaller libraries. You can always do `#lang racket/base` and include the subset of libraries you need.
> And I share Alex Shinn's opinions on syntax-case.
Not to talk shit about Alex -- he's a smart guy and Chibi is a very nice system -- but he's both seriously misinformed about syntax-case and hopelessly obstinate about it. Despite his claims that syntax-case is super complicated to implement, it's really not much more complicated than syntax-rules: it uses the same pattern language, but rather than a template, it's associated with an expression. The only thing "extra" that's needed is a disjoint `syntax` type, which is just a wrapper around the other primitives with a bit of implementation-defined context (the crucial bit of context, for purposes of hygiene, being the syntactic environment; apart from API, a `syntax` value is really just a syntactic closure). The thing is, syntax-case has been shown to be able to express anything er-macros and synclos can express, but the reverse is not true, meaning that it's very possible that syntax-case is strictly more powerful than the alternatives.
I honestly think Dybvig and company did a disservice to syntax-case by making psyntax so complicated. I think one of their goals was to make psyntax production-quality, but I think it would have been better to make it as simple as possible -- just the bare essentials, for illustrative purposes. People tend to take it as exemplary because it's what they've got, but it really is a bad example because in its desire to be real-world and practical it obscures the intuition behind the system. Dybvig's entry in "Beautiful Code"[0] helps considerably, but I still maintain that the essence of the system is simpler than it's portrayed even there.
While I think that ir-macros are often very nice, there's no denying that the pattern matching offered by syntax-rules/syntax-case is extremely convenient and, more often than not, extremely clear. Many of the macros that are full of cadrs and caaaddddrs and cddaaars find a much more convenient and readable expression in the pattern language.
[0]: http://www.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf http://www.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf
- qwertyuiop924 10y agoIn your hygenic macro systems list, you forgot sc macros. Anyways... >However, it's not "hygienic by default" -- you have to go out of your way to manually and explicitly ensure your er-macros are hygienic. Leave out a ,(rename 'foo) somewhere, and suddenly you've broken hygiene. Same problem with gensym, really, except that rename is a little nicer to use. Well, I didn't say it was a great system, I just said if was hygenic, for the given value of hygenic. >It's also a proposed addition for R7RS-large (SRFI-139). Thanks. That actually does look pretty neat, although a bit odd in some ways. >It's all in libraries. `#lang racket` is just a "metalibrary" that exports a bunch of smaller libraries. You can always do `#lang racket/base` and include the subset of libraries you need. Well, there is that... But I'm still not a huge fan of Racket: I dislike where they diverged from Scheme (mcons? really?), syntax-case STILL leaves a bad taste in may mouth (see below), and the system as a whole just feels overly baroque to me. >Not to talk shit about Alex -- he's a smart guy and Chibi is a very nice system -- but he's both seriously misinformed about syntax-case and hopelessly obstinate about it. Despite his claims that syntax-case is super complicated to implement, it's really not much more complicated than syntax-rules: ...I don't think that was Alex's objection to syntax-rules. It isn't mine. My objections are as follows: -Breaking the standard macro abstraction by saying that expressions aren't, in fact, sexprs. -Presenting an overy complex API to the programmer: lots and lots of functions, and a whole new read syntax. -the (lambda (stx)) wrapper basically breaks every existing macroexpander, which, if it had a defined format in a given Scheme, probably used the format defined by sc. Why define that anyways?
- soegaard 10y agoJust a quick note to inform you that Racket now uses a new model for macro expansion. It is based on sets of scopes rather than the mark model used in syntax-case. http://www.cs.utah.edu/plt/scope-sets/ The new model has also been used by Tim Disney and others to make macro expander for JavaScript (see the sweet.js project).
- qwertyuiop924 10y agoAt a glance, that looks a lot like that Syntactic Closures model: Modeling the environment as both mappings between variables and values, and identifiers and variables. However, I fail to see how renaming is problematic in recursive macros, save being unweildy. I'm not sure, but AFAICT, this may be a solution in search of a problem. It is interesting though, and might be an actual better solution. It's hard for me to tell without a long, slow readthrough, which may happen later. But this is just a concrete instance of my opinion of Racket in a nutshell: Cool ideas, but sometimes overly complex for my liking, interesting systems that don't always mix well, a syntax over the ideas that I find distasteful on occasion, and documentation that is comprehensive, but hard to understand. It's okay if you like it, and it's a good language for Getting S%#! Done, but it's not really my thing: I prefer Chicken: Simpler, less academic and cutting edge, but still really good at Getting S%#! Done. But that's my problem, not Racket's