Sweet.js - Sweeten your Javascript (by Mozilla)(github.com)
github.com
Sweet.js - Sweeten your Javascript (by Mozilla)
http://github.com/mozilla/sweet.js
29 comments
http://news.ycombinator.com/item?id=4560691 <- (posted here three weeks ago, using https:// instead of http://)
Interesting and impressive from a technological perspective but wouldn't sweet.js make your code harder to debug? Macros in C are hell. Have you seen functions with ifdef littered everywhere? Why would anyone want this in JavaScript? JavaScript is dynamic enough to not need a crutch like this in my opinion. At least with CoffeeScript you're not mixing contexts. Everything is either CoffeeScript or JavaScript.
Macros in C are a far cry from hygienic macros: http://en.m.wikipedia.org/wiki/Hygienic_macro.
Reading about Sweet.js made me really, really want such a thing in Python.
I recognise that such a thing would run completely counter to Python's 'no magic' cultural values, but structural search-and-replace seems such an intoxicatingly powerful tool, I'd like to at least have the option to abuse it.
I recognise that such a thing would run completely counter to Python's 'no magic' cultural values, but structural search-and-replace seems such an intoxicatingly powerful tool, I'd like to at least have the option to abuse it.
So use Perl :)
The thing about Perl is that there is supposed to be more than one way to do it. Which enables you to mix-and-match different paradigms in a way that the Python philosophy doesn't seem to welcome.
Or just use a Lisp.
The thing about Perl is that there is supposed to be more than one way to do it. Which enables you to mix-and-match different paradigms in a way that the Python philosophy doesn't seem to welcome.
Or just use a Lisp.
I'd suggest that metaclasses are Python's 'equivalent' for magically mutating things.
I'm pretty sure I seen someone doing python macros using a custom codec: http://docs.python.org/library/codecs.html
Not a ‘new JS’ with ‘better’ syntax, but convenient means for developers to define their own JS with the syntax most suitable for the problem at hand. Reminded me of “You're solving the wrong problem” post[0].
For good or bad, it appears to be limited, with macros you probably can't, for example, make curly braces optional.
[0] http://news.ycombinator.com/item?id=3561397
For good or bad, it appears to be limited, with macros you probably can't, for example, make curly braces optional.
[0] http://news.ycombinator.com/item?id=3561397
If I recall correctly, there might be a macro system in the ECMAScript 6 specification (which should be implemented natively by Javascript engines eventually).
That not correct -- no new features are being added to ES6 now. Macros are possible for subsequent versions, though.
Ah ok, I think I first heard of it here and thought it would be included in the spec: http://brendaneich.github.com/Strange-Loop-2012/#/41
he mentioned it teaser-style in the slides.. don't know what he actually said:
http://brendaneich.github.com/Strange-Loop-2012/#/41LLJS and Now Sweet JS
Seems like mozilla is trying to answer TypeScript. Which is really good.
Seems like mozilla is trying to answer TypeScript. Which is really good.
But they are not solving the same problem at all! This should be a superset of TypeScript. Since TypeScript is a superset of JavaScript, you would not be forced to use TypeScript if you didn't want to. But how can I use this with TypeScript currently?
I was wondering about integrating the two. The only way I can think of is for sjs to sit on top of TypeScript. It would not have to specifically understand TypeScript, instead there could be a macro file for everything TypeScript. These macros would just pass things through.
Currently sjs doesn't support changing syntax, so this is probably not currently possible as described.
No. I never want to say TypeScript is bad or not. But I wan't to say is, Mozilla is trying to do something competitive with TypeScript or may be with CoffeScript.
Which is really good.
Which is really good.
Mozilla has been working on this since before Aug 1: https://github.com/mozilla/sweet.js/commit/de15
I don't think they know anything about TypeScript before it was made publicly available, which happened a week ago or so.
I don't think they know anything about TypeScript before it was made publicly available, which happened a week ago or so.
Okay. I think this discussion leads to something not useful. :)
We have CofeeScript, TypeScript, LLJS (have no idea when this will be usefull), Sweet JS.
So It's about choices. That is good.
We have CofeeScript, TypeScript, LLJS (have no idea when this will be usefull), Sweet JS.
So It's about choices. That is good.
A technical question: how do they get require()ing .sjs files to work, as opposed to compiling and require()ing the output? Is there some way to add hooks that change the behavior of require() to insert a compilation step?
There is indeed. Take a look at require.extensions:
http://nodejs.org/api/globals.html#globals_require_extension...
http://nodejs.org/api/globals.html#globals_require_extension...
Neat! With a little bit of googling, it seems CoffeeScript can do the same thing. That lowers the barrier-to-usage of compile-to-js languages enormously!
Now I'm looking at the sweet.js source where they register the extension, and there's some additional magic I don't recognize; is module._compile documented somewhere that I just can't find, or is that getting added somewhere in the sweet.js code?
Now I'm looking at the sweet.js source where they register the extension, and there's some additional magic I don't recognize; is module._compile documented somewhere that I just can't find, or is that getting added somewhere in the sweet.js code?
I don't think it is. I seem to recall Isaac saying that he considers require.extensions to be a mistake, though I don't know if he meant the concept (extensibility) or implementation (register hooks under filename extensions). Either way, I think it's recognized that a lot of people enjoy and use the functionality so it's unlikely to go away.
As an aside, here's the relevant bit of code that loads the (already compiled) source as a module: https://github.com/joyent/node/blob/master/lib/module.js#L40...
As an aside, here's the relevant bit of code that loads the (already compiled) source as a module: https://github.com/joyent/node/blob/master/lib/module.js#L40...
What are "hygenic macros" and why we should import them from Scheme and Rust?
http://en.wikipedia.org/wiki/Hygienic_macro
Hygenic macros are limited to 'safe' operations. They let you extend the language without creating opportunities for incredibly complex and hard to debug stuff like you can do with un-hygenic macros, for example C macros.
Hygenic macros are limited to 'safe' operations. They let you extend the language without creating opportunities for incredibly complex and hard to debug stuff like you can do with un-hygenic macros, for example C macros.