Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Since sweet.js code can't be directly run in the browser, you need some "compiling" or "interpreting" step. It's not obvious why this is any different from a compile-to-js language that had support for macros.

For example, someone wrote a macro system for coffeescript: https://github.com/mrluc/macros.coffee

Related discussions: https://github.com/jashkenas/coffee-script/pull/3171 https://github.com/gkz/LiveScript/issues/328



This isn't intended for people interested in other languages; if you like CoffeeScript, certainly use it. I really like ClojureScript myself. But there's a lot of reasons you already need a build step for JS anyway (especially for client-side), and this gives you a lot of power without having to completely switch languages.

It's worth noting that sweet.js is a robust macro system grounded in academic research (the core of it from the Honu paper). That CoffeeScript system is a bit of a hack and its flaws would show it the whole community started using it (I don't have time to go into this right now, but things like hygiene, etc are really difficult).


Hi, I made macros.coffee, and I'd like to say that this guy is right. It's non-hygenic (on purpose) and it's a hack.

And purely a labor of love! Slides: http://mrluc.github.io/hammy/12-7-rum-macros/deck.html#1 Code: http://mrluc.github.io/macros.coffee/docs/macros.html

I wanted to see how easily I could add (non-hygenic) macros to CoffeeScript, and if I could do it as an npm-installable module instead of a fork of the language.

It was also an experiment in making macros very clear to myself. Non-hygenic (CL-style) macros are very simple conceptually.

But the basic hack that made it possible to get true CL-style macros also makes the whole thing incredibly dependent on the structure of the CoffeeScript AST. Which makes it fragile.

I'm excited by BlackCoffee, actually. This is the first I've heard of it. Thanks a lot for giving me a nod in the github PR, and of course let's mention Oran Looney as well, who wrote the best deepcopy ever for Javascript (I wrapped this up as owl-deepcopy and made an npm module for it).


You can think of sweet.js like a modular compiler. Let's say you wanted to use the @ syntax or the -> function syntax from coffeescript. Include a macro that does it rather than build a full compiler to do it. Coffeescript could then be a collection of macros rather than it's own compiler. Those macros could be shared across other projects or you can pick one or two for a lightweight Coffeescript-esque experience without having to port your whole codebase.

There's a point where I think this breaks down. It's great for syntactic sugar but I think things like type analysis would become a bit more difficult.


The Lisps in which this concept has its heritage call that step "macro expansion". Granted that that won't happen properly if you use script tags to load a file of Javascript with macros -- but consider, for example, the possibilities inherent in making macro expansion an integral part of the loading process carried out by a library like Require.js. Macro expansion tends to be a lot lighter-weight than compilation does, because it's a simpler transformation; there's no obvious reason why integrating it into Require, or a similar library, should be particularly difficult to accomplish.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: