disnet

We're working on integrating macros and modules to address this. Once it's implemented you'll be able to do something like `import { m } from "macros.js"`.

Yes indeed. Sweet.js already uses syntax objects internally so the groundwork is there for syntax-case. We "just" need to implement and surface the API :)

> The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable.

True, but the same can be said of any API. Reading the definitions can help but for both complex macros and complex APIs built today out of just functions and objects you need to document your abstractions. Macros don't change this, they just give you another abstraction axis (syntactic) to work with.

As with most things it just depends on how you use it. Sure you can abuse macros to make tons of crazy, undocumented, hard to understand syntactic extensions that destroy readability. But you can already do that today. Used wisely macros can increase readability, used poorly they can decrease it.

> And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?

Not sure what you mean here. By definition macros are expanded at compile time (well, parse time really). The browser doesn't change this.

> OK, either your description page doesn't get your point across at all, or you're missing a definition somewhere.

The description page (like the rest of the project at them moment) is definitely a work in process. Sorry about the confusion!

> 'Wish the function keyword in JavaScript wasn't so long? What if you could define functions with def instead?'

> Erh, no? Why in the lord's name would I ? Is that your big selling point? 'I don't like function() because it's too long?'

This is just a really basic example of what you can do. Obviously you could have the same effect with sed but we need something simple to shows what basic macro definitions look like.

> 'Want a better way to make "classy" objects?'

> <provides example that looks like php vomited on Javascript after mating with ruby>

I'm assuming you refer to the macro definition with $ and whatnot. If you have ideas for better syntax please contribute! The notation is by no means final. That said I think it's pretty good for what it needs to do, matching syntax patterns and transforming them into new bits of syntax. Certainly more readable than a full parser/compiler.

> Am I the only one that doesnt understand the use case of this? Or is it just another lexer/parser?

The idea is to provide a middle way between no syntax extensions and writing your own full compile-to-js language languages like CoffeeScript which allow you to add any kind of syntax you want, but at the expense of being able to compose extensions. If you like the class notation of CS you must buy into all the syntax choices of CS whereas macros allow you to add just the syntax you want.

Whether you want new syntax is of course a different question. Other languages like scheme and closjure have found macros useful so sweet.js is an experiment to find out if the same syntactic extensibility that they provide is useful in JavaScript.

Hope that helps!

Yeah there are certainly a few bugs remaining in the reader :)

It actually does the right thing if the function is named:

    a = function foo() {}
    /5/
    7

correctly translates to:

    a = function foo() {
    } / 42 / 7;

But clearly I missed the unnamed case. You mentioned finding a few other bugs? Would you mind submitting a bug report on github? I would love to fix those too!

I've found the path of least resistance is to not change the default keybindings of the various emacs packages. Use the vi bindings for text manipulation and when you need to invoke a package function it's back to the ctr/meta chords. It's the text manipulation that's burned into my brain so as long as vimpulse takes care of that I'm mostly happy.

It's true though that if you're heavily invested in vim plugins there's fair time sink in getting up to speed on the emacs equivalents. Everything's a tradeoff.

I haven't done any benchmarks yet so not sure. In addition to the guards I think the use of Proxies will cause some slowdown. But you're right the JIT should be able to optimize most of those guards away (maybe even someday use the guards to help in their optimizing/tracing...just speculating here, I'm not a compiler/JIT guy).

If you compile with "coffee -c" (compile, no contracts) instead of "coffee -cC" (compile, with contracts) you get pure JavaScript, no contracts and no runtime checks. Exactly what vanilla CoffeeScript would have given you.

Well, CoffeeScript/JavaScript doesn't have a static type system. And to add one would be...hard.

But we would still like to express and enforce some invariants about our code. And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."

Contracts also allow us to check invariants that might not result in a run-time exception but could lead to the code just being subtly wrong.