Hacker News new | past | comments | ask | show | jobs | submit login
The Complete Annotated CoffeeScript Source (jashkenas.github.com)
36 points by jashkenas on March 8, 2010 | hide | past | favorite | 15 comments

CoffeeScript is implemented in CoffeeScript itself, and this is the unabridged source code for it, in literate programming style.

Quick links to other interesting bits (also accessible from the "Jump to" link on that page):

The Lexer, which has some extra smarts to help keep the grammar cleaner than it otherwise would be:


The implementation of lexical scope:


The "coffee" command-line utility:


All of those pages are created by a little literate-programming-style documentation generator called "Docco". If you run it on itself, you get this:


Hopefully we'll get some good patches from having the source in the open like this.

Having poked around the source as part of implementing full vim support, I believe that nodes.coffee [1] exercises every single coffeescript feature except splats and js escaping, so that might be interesting to people as well even if it is a less interesting part of the source.

[1] http://gr.ayre.st/s/nodes.coffee.html

Also, this isn't 0.5.5? Waiting for interpolation to settle?

* I'll put out my vim stuff when I write the indent script.

So if CoffeeScript is written in CoffeeScript, does that mean that the developer had to compile it by hand the first time and is now using each version to compile the next version?

The original compiler was written in Ruby, and CoffeeScript started out life as a Ruby gem. Once the language reached a reasonable stage of completion, we ported it over to CoffeeScript and axed the Ruby version.

Now, every time that you run "bin/cake build", you re-write your entire compiler.

It's pretty fun stuff -- if you're working on the language and you break something, guess what, you no longer have a working compiler to dig yourself out with.

So the usual pattern for language work (bin/cake build:full), is to check out the "lib" directory (in case you broke it), rebuild the compiler twice, to get your modifications built-in, and then to run all of the tests.

Though I appreciate the code, and will definitely read through it, and I like the idea of a self-compiled language... that seems like more hassle than it's worth (very specifically the double-compilation / failed => super.fail part. A compiler in the language it compiles has advantages for the programmers using it, among other things).

Normally nowadays you would write two compilers: one for a subset of the language in a different but ideally similar language, and a second compiler in the subset that hopefully is a fairly straightforward translation of the first compiler. After the second compiler is able to compile itself, you're bootstrapped.

just noticed coffeescript for the first time. i think there's a need for a clean, simple, eager, dynamically typed functional language and i'm wondering if this fills the spot.

i realise that is not exactly your aim, but in that context have you thought about adding linked lists (which would complement javascript arrays)? also, what does function composition look like? is currying supported?

CoffeeScript is just JavaScript, so to the extent that you can compose and curry functions in JavaScript, the same is possible here. Either directly, or through libraries like Oliver Steele's Functional.js, or Underscore:


As for adding linked lists, we have something of a golden rule with CoffeeScript -- there are no special objects or functions added to the runtime (with a couple miniscule exceptions). We're not building a standard library, because that would open Pandora's box, and there would be no end to the project's scope. Instead the idea is just to show a certain side of JavaScript in a different light, and to work seamlessly with whatever libraries (server-side or client-side) you choose to use.

ok, i understand. not quite what i'm looking for, then, but thanks...

Haskell can be compiled to Javascript. Perhaps that's what you're looking for?


Haskell has dynamic typing via the Data.Dynamic module, but I don't find it to be useful. I can't think of any reason why anyone would want dynamic typing, anyway. Eventually you need to know the type of your data, why not figure that out before you start the program running? (But if you disagree, Haskell is not going to stop you.)

No, it's not what I want thanks. It's not eager and it's not simple and it's pretty fiercely pure. What I am thinking of is something more like a functional Python, or a Scheme with a "nice" syntax.

Use Scheme for more than five minutes and I think you'll find you don't care about the syntax anymore. Plus you won't have to write your own language, which is always nice.

Strict evaluation is a pain, though, IMHO.

Thanks, but I have used Scheme for more than 5 minutes.

[edit: more generally, what is the point of this conversation? You've stated that you don't understand how anyone could want dynamic types, and that strict evaluation is a pain. It's pretty obvious that you want completely different things to me. Given that, are you really trying to help me here, or just being a bit of an asshole? You're welcome to disagree, but simply repeating your opinions as if they are somehow more valid than mine isn't helping anyone.]

He's not being an asshole, he's just trying to help. Perhaps if you were a bit more forthcoming about what you do want (or why you don't want X), his comments might be a bit more on target.

Well, at least my comments aren't one sentence saying how the other person is wrong with the overtone of "no, that's not good enough, I am a unique flower and eveyrone else is wrong".

Er, this one is, but...

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