Hacker News Reader

Comment by jlongster | Hacker News Reader

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.

View on HN

> 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.

> 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.

Do 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.)

The 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.

I 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.

But alas, the browser wars are upon us once again. FF vs Chrome is approaching the silly.

On the other hand, there are merits in their differences. Chrome, although it would prefer Dart, looks upon JS as legacy that they can approach via a good VM/JIT, and a brilliant Developer Tools suite.

FF on the other hand is leading into the JS futures on two fronts: asm.js for both performance and C/C++/.. integration into the browser, and ESnext. Google is very reluctant to invest in ESnext now, just look at the compatibility charts.

This makes sweet.js strategic, it lets us at least experiment with ESnext features as far as macros can take us. I'm hoping sweet.js can also help us make use of asm.js from within the browser buy building macros for things like structs, which halve or more memory footprint of object arrays.

Lets be aware of the war, and do what we can do to resolve it.

The syntax "crowding" could be solved by scoping macro rules. Maybe `macro class, foo, bar` at the top of the file?

The 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.

Racket shows how, with strong module support, a whole "tower of languages a.k.a. macros" can work reliably. Else not so much.

Also, macros in racket are lexically scoped. Any modern macro system should follow their design, IMHO.

Agreed, and happily sweet.js is very consciously modeled after Racket.

That's the best thing I read this morning and a reason why I'm going to give sweet.js a closer look :)

I 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.

Reply on news.ycombinator.com