

The Complete Annotated CoffeeScript Source - jashkenas
http://jashkenas.github.com/coffee-script/documentation/docs/grammar.html

======
jashkenas
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:

[http://jashkenas.github.com/coffee-
script/documentation/docs...](http://jashkenas.github.com/coffee-
script/documentation/docs/lexer.html)

The implementation of lexical scope:

[http://jashkenas.github.com/coffee-
script/documentation/docs...](http://jashkenas.github.com/coffee-
script/documentation/docs/scope.html)

The "coffee" command-line utility:

[http://jashkenas.github.com/coffee-
script/documentation/docs...](http://jashkenas.github.com/coffee-
script/documentation/docs/command.html)

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:

<http://jashkenas.github.com/docco/>

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

~~~
grayrest
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.

------
simonw
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?

~~~
jashkenas
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.

~~~
Groxx
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).

------
andrewcooke
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?

~~~
jashkenas
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:

<http://documentcloud.github.com/underscore/#compose>

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.

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

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

<http://www.haskell.org/haskellwiki/Yhc/Javascript>

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.)

~~~
andrewcooke
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.

~~~
jrockway
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.

~~~
andrewcooke
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.]

~~~
anthonyb
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.

