I'm pledging $1,000 to this. As the author of the PragProg book on CoffeeScript (<a href="http://pragprog.com/book/tbcoffee/coffeescript" rel="nofollow">http://pragprog.com/book/tbcoffee/coffeescript</a>), I have a stake in making CoffeeScript a more mainstream tool, and I believe that Michael's project will greatly advance this cause.<p>The use of CoffeeScript has become fairly widespread at startups (GitHub, 37signals, many YC alums...) but not in larger enterprises. One reason for this is that debugging CoffeeScript requires a "hacker mentality": compile-time errors are often reported with minimal or misleading explanations (e.g. "Unexpected ," when there is no comma on the line, but rather an implicit comma from whitespace); run-time errors have to be manually traced from the compiled JS to the original CoffeeScript.<p>These flaws are likely to be ameliorated gradually (Jeremy has stated that Source Map support is the primary goal for CoffeeScript 1.4), but this project could improve the debugging situation dramatically in a matter of months. I hope the CoffeeScript community will lend Michael their support.
Having poked around with Jeremy's compiler (I forget if I've sent in patches or not), I'm curious about some of the technical details behind the project. I've thought about this topic for a while and this is a rather disorganized brain dump Feel free to respond to as much or as little as you like.<p>The main complaint I have with the current compiler is the inability to control output either via compile time macros or compiler hooks. I would <i>like</i> to map Coffeescript's class construct onto the class system of a variety of frameworks. I understand most of Jeremy's rationale but I still have to patch my install to change the superclass name in order to map coffeescript classes onto yui3 (same pattern, different superclass names) and I'd really like to see the class syntax map to Ember's classes.<p>Any particular reason for PEGs over Parser Combinators?<p>From reading, looks like you plan to skip the rewriter pass. I started a PEG parser implementation in the 0.3 timeframe but ran into problems with the `x = a: 1, b, c` -> `x = {a: 1, b:'b', c:'c'}` and similar ambiguities. Do you have a plan for handling this? Will you drop language features if you can't do them without rewriting?<p>What sort of compile time hooks are you planning? Just (C)AST->(J)AST passes?<p>In the time since I've messed with coffeescript internals, I've run across two potentially useful things that I haven't really investigated:<p>* <a href="http://www.mirah.org/wiki/Macros" rel="nofollow">http://www.mirah.org/wiki/Macros</a> <- macros in a non-lisp langauge<p>* <a href="https://github.com/cgrand/parsley" rel="nofollow">https://github.com/cgrand/parsley</a> <- fully incremental parser generator<p>The latter is interesting because it'd potentially allow the actual compiler to be used as the starting point for language IDE support.<p>Good luck, I'll be following your progress with interest.
One feature that would be helpful is support for the Google Closure Compiler's "Advanced Mode" in the generated javascript (coffeescript right now stumbles with the property renaming, especially when destructuring is used) I wish I could run this powerful "whole program optimizer" against my coffeescript code.
Separate to the idea itself, this KS made me realise there's an art to choosing the right rewards and levels. Some KS are just irrestible to donate to partly because they get the rewards just right. Others, like this one IMHO, don't make the most of it.
I have this hope, however irrational, that compilers and similar projects become more common on Kickstarter. This is currently the only search result for “compiler”, which feels…wrong, somehow. If I’m not doing anything else this summer, I might just put up a language project and see if I don’t get laughed off the stage.<p>Of course, it’s hard to offer good “prizes” (or whatever—Kickstarter doesn’t seem to have a term for them) for a project that of right ought to be free and open. This guy had the good sense to offer services, but I could see an “enterprise” edition working out as well.
I like CoffeeScript but I see it as a temporary language providing cool syntax features on top of Javascript.<p>no offense but IMHO, we should focus on releasing the next Javascript and make it possible instead of writing better CoffeeScript compilers.
I've made a some progress in this.<p>PEG didn't quite cut it for left-recursion so I created a new parser.<p><a href="https://github.com/jaekwon/joeson" rel="nofollow">https://github.com/jaekwon/joeson</a><p>The grammar for CoffeeScript is getting there -- enough to parse the project files at least.<p><a href="https://github.com/jaekwon/joeson/blob/master/joescript_grammar.joe" rel="nofollow">https://github.com/jaekwon/joeson/blob/master/joescript_gram...</a><p>Michael, we can collaborate on this. Send me a msg on github or email `jkwon.work` at gmail.
How about improving coffeescript language? I tested in on a small project recently and run into lot of ugly edge cases, where I had to read the generated code to find out that coffeescript compiled code differently than my expectations were?<p>example: <a href="http://t.co/omIdeNGA" rel="nofollow">http://t.co/omIdeNGA</a> (jQuery chaining)<p><pre><code> # I'd expect these two blocks ...
$output
.html 'a'
.prepend renderedHtml
$output
.html ('a')
.prepend renderedHtml
# ... to generate exactly same code as this:
$output
.html('a') # you cannot put whitespace or omit parentheses here - but in other places, you are guided to remove them and use spaces
.prepend renderedHtml
</code></pre>
Coffeescript:<p><pre><code> $output.html('a'.prepend(renderedHtml));
$output.html('a'.prepend(renderedHtml));
$output.html('a').prepend(renderedHtml);</code></pre>
I don't really see the benefits of this over the existing compiler. The changes sounds like they could be merged into the existing compiler as command line arguments with relative ease.
I wonder what are the advantages/disadvantages between a PEG and say, a Pratt parser (<a href="http://javascript.crockford.com/tdop/tdop.html" rel="nofollow">http://javascript.crockford.com/tdop/tdop.html</a>)?
I donated 25. CoffeeScript and derivates is the right approach to improve compile-time problem detection with the typeless javascript<p>Thanks for posting
Someone capable of writing this kind of software will earn much more than $3000 per month at a full time job. I understand that this is probably not a for-profit project but if the guy can dedicate 4 full time months to this than he:<p>1) Can work full time
2) Needs the money<p>Why not find a regular programming job that will pay you much more?He is obviously skilled enough to be hired.
Is there any reason the compiler should be written in Javascript? I know it's pretty cool to have a language's compiler written in itself, but what if Javascript isn't the best environment to write a compiler?