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

12 pointsby jay_kyburz12 anni fa11 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.

5 comments

verseda12 anni fa

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

jay_kyburz12 anni fa

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.

verseda12 anni fa

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.

jay_kyburz12 anni fa

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.

[deleted]12 anni fa

jay_kyburz12 anni fa

Thanks to @Delapouite for the link to LiveScipt

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

http://livescript.net/#

onn12 anni fa

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.

jay_kyburz12 anni fa

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.

jay_kyburz12 anni fa

Thanks for the link. Reading the good discussion now.

xpaulbettsx12 anni fa

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.

yamalight12 anni fa

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.

pm12 anni fa

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.