Someone should implement CoffeeScript as macros. That would get everyone's attention.

No, that would get all the CoffeeScripters attention. I believe it is slated though.

I much prefer raw javascript + macros. In my opinion it kind of negates some of point of coffeescript since you can implement the few key syntax improvements.

Yeah, that's a good point, but if you got all the CoffeeScripters' attention and then showed them that CoffeeScript is just one possible improved syntax...

I was speaking to one of the Sweet.js developers about this, and apparently the only obstacle is that Sweet.js doesn't have the ability to make whitespace significant. Other than that, it should be entirely possible.

> Sweet.js doesn't have the ability to make whitespace significant

Feature, not a bug? But yeah, I guess that would be an impediment to implementing CoffeeScript. I'd like to see some of the CoffeeScript syntax implemented but without whitespace dependency (so it would have to be a modified version of the syntax).

I get a

    TypeError: Cannot call method 'getValue' of undefined

on the last example. Running Chrome on OS X.

The last couple of examples appear to be offset by one (with a middle example apparently missing), and thus the last one tries to run nothing.

that's not the direction language and programmers should follow

What exactly do you mean? Macros seem like a good way to solve many of JavaScript's syntactic shortcomings while maintaining backwards-compatibility.

Now, macros do have some shortcomings. I've used Racket (a variant of Scheme) a fair bit, and I'm now very wary of using macros too much. However, when they are useful, I've found they're very useful: writing the same program in a language without macros would often be extremely awkward.

Of course, if you're willing to entertain radical changes to your language, you can get many of the benefits of macros with a minimalist syntax, laziness and a simple mechanism for controlling how statements get evaluated. Which ultimately just amounts to Haskell. And I've even found good use cases for macros in Haskell, albeit far less than in any other language.

One problem I see is that it helps creates more way to do basic things like declaring a class or a function. (There are already a number of different utility libraries for OO in JS).

Now imagine if every JS codebase use a slightly different convention for class/function declaration with slightly different behaviours. It can become a nightmare to understand even the most simple function definition, just because you don't this particular "def" has some side-effects.

Now, I agree that in some cases, macros can be useful and reduce the complexity of the program, but declaring classes and functions certainly isn't the best use case for them and it's a bit sad those are the two first examples on the page.

I see at least two problems:

- debugging such code is a nightmare(node.js itself makes it hard enough)

- static analysis of such code is not possible.. yet?

JS and programmers should target Java-like experience imo, static analysis, code assist, dependency check - all of it performed on-the-fly. We won't get it by creating yet another layer above main language, because IDE vendors simply can't cope.

Javascript is a dynamic language. And especially one that is difficult to do static analysis on. We get much more out of macros than we would with some attempts at static analysis, when it comes to programmer productivity in the end.

problem of static analysis in JS code is difficult, yet it's worth to solve,

coolness of JS and safety of static analysis, that would be great

macros are just lame workaround:)

100% agree. This whole "let's build another language/compiler" on top of JavaScript thing is starting to piss me off.

It's one of those things that just ends up in utterly huge amounts of excruciating pain with respect to performance, debugging, support, fungibility and value over a long period of time.

Agreed, this looks horrible.