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

41–50 of 67 posts

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

#41

Post by oliverkofoed »

jashkenas wrote: post #8
leif wrote: post #7

Beautiful! (I finally made it to the end of the article where you ask about block delimiting...) I think there are two issues, one being that '........' at the end of a large nested expression is ugly, the other being that it's hard to find the start and end of a block as it stands. Since you seem to borrow a lot from ruby, why not add {} and/or begin/end as options? I would definitely keep the period syntax around (…

Yeah, the periods to end block scope are the part of the syntax I'm the least happy with. I couldn't think of anything nicer without resorting to significant whitespace (which I'd like to avoid). I'd rather not add {/}, or begin/end, because it's easy to determine the beginning of the block, it's just closing it that we need a symbol for. In terms of style, you can certainly indent the period on it's own line if you…

I actually think that the period to end blocks syntax is one of the most interesting things about it. It's such a small thing, but i find it quite intriguing.

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

#42

Post by scott_s »

jashkenas wrote: post #25
tdavis wrote: post #19

Earlier quoted context omitted.

Out of curiosity, what makes you want to avoid significant whitespace? I think it solves the issue quite nicely. For what it's worth, I used to think SW was completely absurd. Then I spent a few years actually writing Python and have no desire to ever go back.

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…

Python does not have multiline lambdas. But Python only uses significant whitespace when it can't use other demarcations. For example, the following is legal:

  a = [
        1,
          2,
            3]

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

#43

Post by jashkenas »

tolmasky wrote: post #37

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(…

Thanks for that. You're absolutely right -- the javascript dynamically-scoped "this" keyword strikes again. I've fixed it in the last commit, by using prototype.__proto__, and adding an "extends" keyword for convenience. You can see it in action here:

http://jashkenas.github.com/coffee-script/#inheritance

It's out with version 0.1.2 now.

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

#46

Post by jashkenas »

tlrobinson wrote: post #44

How do you do object literals with non-indentifier characters in property names? (e.x. { "foo+bar" : "baz" } in JS)

You couldn't, a minute ago. I've just pushed an update to the grammar that allows you to use quoted strings inside of object literals.

Thanks for catching it. I really appreciate folks taking the time to find the little missing pieces.

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

#47

Post by extension »

jashkenas wrote: post #13
extension wrote: post #11

Splendid! This is what JS really needs, a thin layer to clean up the syntax and patch the quirks, without breaking anything. I made the same kind of thing using the actual Ruby parser: http://github.com/jedediah/prettyscript It's only barely usable at this point and I've been too busy to work on it.

Great stuff. The one really interesting overlap between the two -- from taking a quick glance at your readme, is that we're both trying to convert things that otherwise would be statements in JavaScript into expressions. CoffeeScript does this by using the AST to recursively push down returns and assignments requested from outside a block to the final line of each possible branch of execution: http://jashkenas.github…

That's pretty much what I did. There is a polymorphic method to_js_tail on AST nodes that asks the node to emit itself as a return statement. Nodes that are values just prepend "return", blocks forward the call to their last statement, control structures forward to each of their blocks and so on.

That just handles returns. I never implemented statements as expressions in general. I was planning to do that by wrapping non-expressions in anonymous functions but if you can do it by injecting temp variables, that's probably a lot more efficient.

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

#48

Post by jashkenas »

tlrobinson wrote: post #40
jashkenas wrote: post #36

Earlier quoted context omitted.

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…

Alright -- this is fixed with the latest commit. I've enhanced the --no-wrap option to not emit "var" declarations at the top level. If you don't want the safety wrapper, then you probably intend to make them global in any case.

bin/cs now works like a charm. I might pull it back into the main bin/coffee-script executable. Start a REPL if run without arguments ... --run for executing CoffeeScripts via Narwhal... something like that.

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

#49

Post by nir »

jashkenas wrote: post #27
jrockway wrote: post #24

Earlier quoted context omitted.

I am not the author, but I assume because it's nice-looking, and JavaScript already uses it for assignment (inconsistently). Consider: var foo = 42; { foo: 42 } Why make the two concepts different? Also, it's "binding", not assignment.

a: 1 b: 2 obj: { a: 1 b: 2 } Quite right, and internally, both kinds of assignment compile into a CoffeeScript AssignNode. The latter is just tagged as occurring within an object literal. Having the commas be optional in multiline objects also helps make both kinds of assignment look identical. (And I'm calling it assignment because saying "binding" in JavaScript usually means that you're binding a function to a "thi…

Any chance you'll allow equal sign as well as colon? For all of us coders conditioned by years of programming to automatically use "="...

Looks beautiful, in any case.

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

#50

Post by tlrobinson »

jashkenas wrote: post #48
tlrobinson wrote: post #40

Earlier quoted context omitted.

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…

Alright -- this is fixed with the latest commit. I've enhanced the --no-wrap option to not emit "var" declarations at the top level. If you don't want the safety wrapper, then you probably intend to make them global in any case. bin/cs now works like a charm. I might pull it back into the main bin/coffee-script executable. Start a REPL if run without arguments ... --run for executing CoffeeScripts via Narwhal... some…

Great, thanks.
Post reply on HN