Ask HN: Forking CoffeeScript to Fix the Mad Mad Mad Scope Issue | Hacker News Reader

Ask HN: Forking CoffeeScript to Fix the Mad Mad Mad Scope Issue

12 pointsjay_kyburz11 comments

I would be interested to hear about how difficult it would be to fork CoffeeScript and fix the scope issue outlined in these posts.

http://raganwald.com/2013/07/27/Ive-always-been-mad.html

http://lucumr.pocoo.org/2011/12/22/implicit-scoping-in-coffeescript/

http://www.reddit.com/r/programming/comments/1j1cw7/coffeescripts_scoping_is_madness/

I work in Python on the server and JavaScript on the client all day long and I really do think syntax matters.

I would love a client language that was as clean and beautiful as CoffeeScipt but I think this issue is a show stopper for me.

View on HN

"Fixed" is so often an opinion.

CS makes scoping assumptions for you, because it wants to avoid syntactic clutter like "var. Maybe you'd like a different default assumption. Maybe you'd prefer to add in scoping keywords/sigils. These issues are full of tradeoffs.

The worst thing that can happen, though, is for there to be two nearly identical implementations, differing only by their subtle treatment of scope. If you think it's a showstopper now, imagine a world where your code silently manifests a variable binding security hole because you used a different fork of CoffeeScript.

Sure, "fixed" suggests that, in my opinion, the default scoping decision was wrong and I would like to work with something different. My question was not whether or not you agree with me.

Alright, I'll answer the question then.

It's probably quite easy to implement technically. It's probably much harder to come up with a logical, coherent, and consistent model of how it "should" work in all ofthe corner cases.

It's probably extremely difficult to accomplish socially (nobody will use the fork, and nobody will want to touch code that works on the assumption you're running the fork). Finally, it's probably actively damaging to the community as a whole to even attempt to fork over a relatively minor, ambiguous and, and opinionated like this, and I hope nobody tries it.

Thanks Verseda,

If I did take this on as a side project I would have no interest in making popular or having other developers use it. It would be for my internal projects.

There are a number of other things I would do to make the language more explicit. I'm a Python guy not a Ruby guy.

Thanks to @Delapouite for the link to LiveScipt

"LiveScript is a fork of Coco and an indirect descendant of CoffeeScript"

http://livescript.net/#

I was the original reported of https://github.com/jashkenas/coffeescript/issues/238 . And the short answer is: not that easy. Coffeescript wants to keep the semantics of javascript, but it wants to not have the noise of "var x = ..." all the time.

Thanks for the link. Reading the good discussion now.

I understand that what they have implemented was a deliberate decision, but wouldn't actually be easier to simply to identify that a variable is new to a particular scope and generate a var statement at the top of the javaScript function definition?

Does the compiler have any notion of scope?

edit: oh right, you need nonlocal or := if you want to access the outer scope.

Honestly, the solution is to wait for ES6 'let' scope - CoffeeScript's scope issues exist because it is, by intentional design, similar to JavaScript, and JS has scope issues.

When ES6 is a viable option, CoffeeScript can incorporate lexical scope in a backwards compatible way, and its scoping will become much less unexpected.

why wait when you can use it today with 6to5 or traceur? obviously you'll need a build step, but if the app is larger than tiny, you probably already have one.

Have you actually tried writing CoffeeScript? I can't tell from your post, but if you haven't, you should really give it a go first and see how you progress. It might not be as big an issue as you think.

Reply on news.ycombinator.com