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 t

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. 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 like 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. Any particular reason for PEGs over Parser Combinators? 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? What sort of compile time hooks are you planning? Just (C)AST->(J)AST passes? In the time since I've messed with coffeescript internals, I've run across two potentially useful things that I haven't really investigated: * http://www.mirah.org/wiki/Macros http://www.mirah.org/wiki/Macros <- macros in a non-lisp langauge * https://github.com/cgrand/parsley https://github.com/cgrand/parsley <- fully incremental parser generator The latter is interesting because it'd potentially allow the actual compiler to be used as the starting point for language IDE support. Good luck, I'll be following your progress with interest.