6 ms·
You're absolutely right, and we need to establish a good culture that doesn't abuse macros. Of course, some people always will and let's hope we don't have to w
by jlongster 13y ago
You're absolutely right, and we need to establish a good culture that doesn't abuse macros. Of course, some people always will and let's hope we don't have to work with that code.
There are a lot of ripe ES6 features to implement as macros. That `class` macro is actually taken from ES6 and has been standardized for JavaScript, so it's not exactly random.
- pfraze 13y agoThe syntax "crowding" could be solved by scoping macro rules. Maybe `macro class, foo, bar` at the top of the file?
- jlongster 13y agoThe next big thing sweet.js is working on is modules. You will be able to actually pull in macros just like you would ES6 libs: import { foo, bar } from "macros"; The scoping of macros will all stay in tact; any other macros from "macros.js" will be available, but the code that `foo` or `bar` expands to will be able to access them (this is really nice for helper macros and other things). So yes, modules are going to be a big part of distributing and composing macros.
- 6cxs2hd6 13y agoRacket shows how, with strong module support, a whole "tower of languages a.k.a. macros" can work reliably. Else not so much.
- klibertp 13y agoAlso, macros in racket are lexically scoped. Any modern macro system should follow their design, IMHO.
- jlongster 13y agoI just noticed a typo: I said "will be available" when I meant "will not be available". Any macros you don't import will not be in scope.
- drivingmenuts 13y ago> we need to establish a good culture that doesn't abuse macros I'm sure everyone who has ever looked at C macros has thought the same thing. It's a great theory. In practice, having macros will lead to someone abusing them and eventually, that abuse will be become institutionalized. Don't say "it could never happen here" because it can and it inevitably will. I don't have a specific problem with all of this, except I keep thinking a better solution would be to hammer browser manufacturers to keep their shit up to date or explain why they are not doing so.
- yeahbutbut 13y ago> I don't have a specific problem with all of this, except I keep thinking a better solution would be to hammer browser manufacturers to keep their shit up to date or explain why they are not doing so. That's the thing though. When a new proposal comes out, if it's released in the form of a macro it can be tested without vendor buy in. The pressure relief on vendors to keep up to date with the standard is just an unintended (maybe negative * ) side effect. * Personally I like being able to count on "current" features and I'm not opposed to using shims to patch the environment up to a workable level.
- chc 13y agoDo you even Lisp, bro? (Forgive the irresistible pun, but the sentiment is sincere: This feature is based on Scheme, so looking at C seems misguided.)
- jfb 13y agoThe C preprocessor is terrible, but rampant cpp insanity is much, much less prevalent these days -- the C culture has made its peace with the technology. A similar accommodation would doubtless happen with JS macros, particularly as there's almost no chance that the implementation would be as brainless as C's.
- cgag 13y agoI think the Clojure community manages to do pretty well in discouraging macros except as thin sugar over functionality avaible through normal channels. It also has some very complicated macros that give it a type system and lightweight threading and channels that would have have had to be implemented by the language designers in other languages. I'm willing to run into the occasional macro abuse to get goodies like core.async and core.typed.