Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

jashkenas.github.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#31

Post by jashkenas »

aaronsw wrote: post #29
jashkenas wrote: post #25

Earlier quoted context omitted.

I like to have the flexibility to indent in whatever style the code calls for. That said, looking over the Python docs again, their implementation of significant whitespace is a lot more flexible than I remembered. I didn't realize you could do one-line method definitions, and that the whitespace only kicks in when you write a multi-line block. Here's a question for you. In Python, if you have a couple of nested lamb…

No.

Great. Then let's start a "whitespace" branch, and give it a go.

Edit: Alright, got a branch that starts with a little significant whitespace going here:

http://github.com/jashkenas/coffee-script/tree/whitespace

It can't handle the first of the two cases mentioned above just yet, but it compiles the second one correctly.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#33

Post by btilly »

jrockway wrote: post #23

This is nice. There are too many gotchas to remember in JavaScript; better to let a liberal compiler translate something nice into the "machine code" that works in all browsers. (Personally, I always write: something = { foo: "bar", bar: "baz", } which works in Firefox, but not IE. A compiler would not be upset when it omits that extra trailing comma. Of course, you can always write: something = { foo: "bar" , bar: "…

If the second form works and avoids bugs, can't you train your eyes to accept it?

That's what I did in SQL a few years ago, and I can't count how many times it has helped me since.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#34

Post by jashkenas »

jrockway wrote: post #23

This is nice. There are too many gotchas to remember in JavaScript; better to let a liberal compiler translate something nice into the "machine code" that works in all browsers. (Personally, I always write: something = { foo: "bar", bar: "baz", } which works in Firefox, but not IE. A compiler would not be upset when it omits that extra trailing comma. Of course, you can always write: something = { foo: "bar" , bar: "…

Which is why CoffeeScript lets you leave commas out of multiline object and array literals (for those that didn't see catch it in there):

    something: {
      foo: "bar"
      bar: "baz"
    }

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#35

Post by tlrobinson »

Very cool.

I've created a simple CommonJS package that lets you use CoffeeScript on the command line with Narwhal: http://github.com/tlrobinson/coffee-script

If you have Narwhal (http://narwhaljs.org/) just install with the package manager "tusk install coffee-script", then you can create Narwhal modules ending in .cs, or run the command line REPL "cs"

(there are a few problems, such as variables in the REPL are created in a local scope, etc, but this was literally a 15 minute hack, I'll improve it when I have time, or feel free to submit patches)

I'm starting to think of Narwhal as less of a JavaScript platform and more of a VM akin to the JVM... JSVM? It now supports Objective-J ("tusk install objective-j" or "cappuccino"), a proof of concept Ruby implementation ("tusk install cappruby"), and now CoffeeScript.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#36

Post by jashkenas »

tlrobinson wrote: post #35

Very cool. I've created a simple CommonJS package that lets you use CoffeeScript on the command line with Narwhal: http://github.com/tlrobinson/coffee-script If you have Narwhal ( http://narwhaljs.org/ ) just install with the package manager "tusk install coffee-script", then you can create Narwhal modules ending in .cs, or run the command line REPL "cs" (there are a few problems, such as variables in the REPL are cr…

Oh wow. A CoffeeScript REPL? If it can hook right in to the Narwhal standard library, that'll be quite a thing to see.

Looking briefly at your commits, I'll add a flag to disable the function safety wrapper so that you don't need to strip it off. Thanks for the tusk package -- it's quite a Christmas present.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#37

Post by tolmasky »

I believe there is a bug in your object model for handling super. I have tested it and it does indeed work incorrectly (although not in the way I expected it to work incorrectly). Basically, your super calls only work if your class tree is 1 level deep. As soon as you have something like Animal -> Horse -> BigHorse, then it breaks down. This is because super() gets translated to:

this.constructor.prototype.NAME.call(this, args)

So, if we had move on BigHorse, Horse, and Animal, BigHorse would call super (resulting in Horse's implementation being called), but then Horse calls super which again calls Horse's implementation, since this.constructor.prototype still points to Horse.prototype. Thus, you can't continue climbing up the chain. When I tried it though, it seemed to just skip the intermediate classes and go down to the base class, which is of course equally broken. We used to have the same problem a long time ago in Objective-J. The fix is pretty simple, you should just inline the actual class name when dealing with supers:

Horse.prototype.NAME.call(this, args), which then calls: Animal.prototype.NAME.call(this, args)

Hope I avoided you some pain with that one. I remember 3 years ago not understanding why on earth my code was broken and thinking it was algorithmic for the longest time until I realized the entire underlying parts were broken.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#38

Post by jeremyw »

jashkenas wrote: post #16
jcl wrote: post #14

Heh... Might want to choose a file extension other than ".cs".

Yeah, all the good extensions are taken -- .cof and .cfs are already other things as well. None of the tooling in the compiler cares about what extension you use: you can call it .coffeescript if you'd like. I'm going to stick to .cs for the parallel to .js for the time being.

.coffee seems an appropriate balance between overloading the namespace and a too-long common string in one's directory.

The 2- and 3-letter extension tyranny must stopped!

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#39

Post by DougBTX »

jashkenas wrote: post #30
j_baker wrote: post #22

Earlier quoted context omitted.

Python's requirement of indentation is somewhat limiting in terms of what the language can do. For instance, that's partly the reason why Python doesn't allow more than a single expression in a lambda.

It doesn't? Is there some kind of documentation about it we can look at?

Try: http://docs.python.org/dev/3.0/glossary.html#term-lambda

Sounds good that you are going to give significant indentation a try.

Re: CoffeeScript, a little language that compiles to JavaScript. Happy Holidays, HN

#40

Post by tlrobinson »

jashkenas wrote: post #36
tlrobinson wrote: post #35

Very cool. I've created a simple CommonJS package that lets you use CoffeeScript on the command line with Narwhal: http://github.com/tlrobinson/coffee-script If you have Narwhal ( http://narwhaljs.org/ ) just install with the package manager "tusk install coffee-script", then you can create Narwhal modules ending in .cs, or run the command line REPL "cs" (there are a few problems, such as variables in the REPL are cr…

Oh wow. A CoffeeScript REPL? If it can hook right in to the Narwhal standard library, that'll be quite a thing to see. Looking briefly at your commits, I'll add a flag to disable the function safety wrapper so that you don't need to strip it off. Thanks for the tusk package -- it's quite a Christmas present.

Indeed it can use all the standard library modules, since the normal "require" functions are available.

The other problem with the REPL is that all variable assignments are prefixed with "var", so they're always local to the function where the eval-ing is done, thus it's impossible to get variables to persist between REPL commands (without explicitly assigning to a property of "global").

One solution would be to add a flag that disables the "var" for top level assignments (but not within functions).

Alternatively, I think I could do some engine-specific black magic (__proto__ hacks), at least for Rhino.

Post reply on HN