Actually, you don't understand lexical scope

https://github.com/raganwald/homoiconic/blob/master/2012/09/actually-YOU-dont-understand-lexical-scope.md#actually-you-dont-understand-lexical-scope

by fogus • 14 years ago

107 68 14 years ago

github.com

btilly• 14 years ago

One addendum. As of JavaScript 1.7 there is yet another way of declaring a variable. It is called let, and makes var work the way it should have worked all along.

Of course you can't rely on people having JavaScript 1.7 in their browser. And even if their browser supports it, if the script tag is not declared correctly, YOUR JavaScript won't be understood to be JavaScript 1.7. So people avoid JavaScript 1.7 features.

I now return you to your regularly scheduled flame war.

raganwald11• 14 years ago

+1. I think that I edited out a sentence where Nickieben used let as an example of JavaScript people agreeing that var was feciform.

andrewcooke• 14 years ago

ok, this is the second hit on google for "feciform" (third is "vomiting feciform matter" while first is "FECI form"). is this really a word? if not, what on earth did you mean?

chr1• 14 years ago

let is slower than var and the way it's likely to be added in jsNext even is even slower (https://mail.mozilla.org/pipermail/es-discuss/2012-September...) the very small improvements it provides aren't worth it

agumonkey2• 14 years ago

I just had an quepiphany. Is it the lambda/scheme culture of defining scope via lambda and application that made javascript having 'only' functional scope ?

k3n• 14 years ago

In a nutshell, you could probably reduce it to that.

http://news.ycombinator.com/item?id=2786720

> Rather than dumb luck, I think a more meaningful interpretation is that I was a piece of an evolving system, exploring one particular path in a damn hurry. That system contains people playing crucial parts. Academic, business, and personal philosophical and friendship agendas all transmitted an analogue of genes: ideas and concrete inventions from functional programming and Smalltalk-related languages.

agumonkey2• 14 years ago

Thanks, I forgot this thread.

emillon• 14 years ago

Probably. But in these languages, variable declaration is also an lambda/application :

    let x = t1 in t2    <=>    (λx.t2) t1

So, it behaves in a sane way (you have lexical scoping for local variables too). There is no "functional scope".

howeyc• 14 years ago

tl;dr - CoffeeScript devs know that if you want lexical scoping you use do.

http://coffeescript.org/#try:foo%20%3D%2042%0A(()%20-%3E%20f...

ynniv3• 14 years ago

The goal of this diatribe appears to be to justify CoffeeScript's design, but to me it counts against it. To be fair, I have never thought CoffeeScript was worth using, but here's the crux:

The pitch: "CoffeeScript is a better syntax for writing JavaScript."

The reality: "CoffeeScript does not behave like JavaScript in subtle, non-syntactical ways."

It is often suggested that people use CoffeeScript instead of JavaScript. But this understanding of CoffeeScript is inaccurate. CoffeeScript has different semantics from JavaScript, and the obvious expansion of CoffeeScript back into JavaScript is a wrong expansion. A knowledgeable JavaScript developer will make mistakes when making simple changes to CoffeeScript code that they did not write. They will have difficulty fixing bugs in CoffeeScript code.

If you like, you can be a CoffeeScript shop. Find senior developers who use CoffeeScript and teach junior developers to use it. Code will be a little easier to write, and, like nerf guns and foosball, you might seem like a superficially cool place to work. Like any new technique, you'll be out on your own. You'll run into bugs, you'll deal with toolchain support, you'll find optimization issues.

There are reasons to translate other languages into JavaScript. Macros, static typing, execution in other contexts. CoffeeScript gives you ruby-like syntax... To me, that just doesn't seem worth it.

raganwald11• 14 years ago

CoffeeScript has different semantics from JavaScript, and the obvious expansion of CoffeeScript back into JavaScript is a wrong expansion

Nothing in the post supports this assertion. You may have your own reasons for feeling this way, but the difference between JavaScript and CoffeeScript with respect to the "var" keyword is neither subtle nor obvious, given that CoffeeScript does not have a var keyword.

The only possible source of literal misinterpretation would be to look at a CoffeeScript file and think that every variable that wan't a parameter was a global variable. This is extremely unlikely in practice.

I read you as being biased against using it. FIne with me, Chief, go your way in peace. But don't try to twist my example into support for a decision you have already made.

ynniv3• 14 years ago

the difference between JavaScript and CoffeeScript with respect to the "var" keyword is neither subtle nor obvious, given that CoffeeScript does not have a var keyword.

Great, then every variable in CoffeeScript must be global, because that's the semantics of a non-parameter not be declared a "var" in JavaScript. Except that this is not an accurate translation, as the entire post goes on to explain scoping in CoffeeScript.

Screwing up scoping is an extremely common JavaScript mistake. If you showed me JavaScript-like code and told me there was a bug, the first thing I would point out is that you declared everything globally. Oh, that isn't the case in CoffeeScript? Huh, I guess you're on your own then, because I didn't learn your goofy alternative JavaScript syntax. Maybe you think the junior kid who has a bug in his code is going to properly explain the subtlety of CoffeeScript scoping.

FIne with me, Chief, go your way in peace. But don't try to twist my example into support for a decision you have already made.

It's offensive of you to dismiss my criticism in this forum. I am not prejudiced against new things, and while CoffeeScript doesn't seem like a worthwhile idea to me, it's community is far more offensive. CoffeeScript's demagoguery of JavaScript might impress some folks, but outside ruby-like syntax, CoffeeScript doesn't solve any fundamental issues.

So, "go your way in peace", and leave me to my thoughts, please.

shaunxcode• 14 years ago

The thing I used to hate about smalltalk was having to define the temporary vars at the top of the method/block. Now it just seems like a great idea which clarifies any sort of ambiguity like this.

lmm• 14 years ago

>the difference between JavaScript and CoffeeScript with respect to the "var" keyword is neither subtle nor obvious, given that CoffeeScript does not have a var keyword

The thing that is subtle and nonobvious as a javascript programmer is the way CoffeeScript variables are scoped. They are not scoped like "var" variables in javascript. They are not scoped like "non-var" variables in javascript either. They have their own kind of scope that is unique to CoffeeScript.

Now you can argue that the way javascript scopes variables is wrong, and I'd agree with you. You can argue that the CoffeeScript way is better, and that's fine. But it makes it a different language from JavaScript, and it has all the baggage that goes along with that. You can't just treat CoffeeScript as "javascript with a nicer syntax"; you need to approach it the same way you'd approach learning any new language.

mistercow5• 14 years ago

>CoffeeScript gives you ruby-like syntax

The implied "only" in that statement seems preposterous to me. For one thing, it's both an over- and understatement of CoffeeScript's featureset, and for another, it's sort of like saying "The printing press just let people print books faster ∗yawn∗."

(Well, OK, so CoffeeScript isn't quite the leap that the printing press was, but you get the point.)

jlgreco• 14 years ago

I haven't looked at CoffeeScript yet (I avoid Javascript work as it is already). What else does CoffeeScript give you?

mattmanser• 14 years ago

Jeremy's reply and the counter reply on the original proggit thread are both very interesting, as is the whole thread if you haven't read it, though the tone is abrasive at times:

http://www.reddit.com/r/programming/comments/zx137/coffeescr...

As is his original reply 2 years ago:

https://github.com/jashkenas/coffee-script/issues/712#issuec...

I think in the end because of the lack of block scope in js he ended up choosing the lesser of two evils really.

He does pass it off a little lightly though as if it's a feature. Jeremy's argument ultimately seems to boil down to 'it's easier for beginners', which is true and noble I think, but on the other hand it's a very easy way to introduce bugs.

It's easy to have a problem domain where you start slipping up, something like a doc with a list of related_docs that you enumerate through, very easy to call that inner variable doc again.

Personally one of the reasons I'm in the camp of favouring explicit variable declaration even if it is a bit of a pita when writing little scripts.

If cs ever becomes the next jQuery and everyone adopts it to make dealing with js that little less painful I could see demands for 'var' and 'use strict' being introduced. Though cs seems to be perpetually hovering on the cusp of mainstream acceptance. I think he sees less complaining about it as if you're at a level where you write enough code that if affects you, you'll be able to figure out and fix it yourself.

raganwald11• 14 years ago

I'm in the camp of favouring explicit variable declaration

So am I, which is why the post explains exactly how to do it in CoffeeScript. I am glad he dropped "var," but I happen to disagree with his design choice for what to do with variables that are not explicitly declared.

But agree or disagree, it is not correct to say that there is no lexical scope in CoffeeScript when in reality people are debating how they want a leaky abstraction automatic variable hoisting feature to work.

benth• 14 years ago

So there is lexical scope, but it requires "do" which means an extra function, something that wasn't required in JS. You don't get lexical scope "for free" in CoffeeScript, there's overhead, unlike in JS. Is that right?

dmpk2k• 14 years ago

But that is unnecessary in CoffeeScript, because if you want lexical scope, you already have lexical scope:

I find that unconvincing -- I like one of Walter Bright's maxims: the simple path should be safe. Unless you're scrupulous about do(), if you do an assignment without the previous definition, there is no error. I'm happy that CS supports it in some capacity though!

Second, CS is supposed to be better that Javascript -- and I prefer many of its features. Apparently claiming that conflating variable definition and assignment is fine, because JS complicates scoping in other ways, is missing the boat. I think everyone agrees that JS's scoping is less than ideal, to put it politely.

Finally, I don't think we should be posting angry articles. The ad hominems and barbs in there aren't raising the level of discourse. :(

nicolasmiller• 14 years ago

Well, actually...

kzahel• 14 years ago

I personally can't stand the style of javascript where each for loop causes a new function scope. It makes debugging extremely annoying. The use of _.each, forEach constructs with function parameters makes debugging all that more difficult. I happily manually type all my for(;;) loops in javascript because when I hit my assertions, I have no problem determining exactly what was going on.

raganwald11• 14 years ago

CoffeeScript has loops and comprehensions for your function-free programming needs. The issue here is what to do when you want to shadow a variable. I am open to correction, however I think in both JavaScript and CoffeeScript you need a function invocation to create a new lexical scope.

prunebeads2• 14 years ago

All this comes from the fact that people think for some reason that coffeescript is a javascript variant. Obviously, it has been demonstrated that it's not: syntax is different, semantics are different.

Also, users of cs shouldn' t have to think about how one language "transpile" to another. Otherwise what would be the point of using cs? If coffeescript designers have provided a clear documentation of their language behaviour, users should refer to it, and not make wild guesses of how it behaves, or how it translates to js.

That said, I'm not an expert of either language.

adgar2• 14 years ago

You might be wondering why people think that. Here's why: it's the entire point of CoffeeScript. According to the first two intro grafs at coffeescript.org:

> CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

> The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, passes through JavaScript Lint without warnings, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.

prunebeads2• 14 years ago

That's a misunderstanding it seems. The real meaning is that "under the hood, it's javascript", and not "it's like javascript". People read "It's just Javascript", and jump to the second meaning, without thinking of the first, but the rest of the text is pretty explicit.

jhrobert• 14 years ago

OK, so coffeescript is really slow at implementing "local variables".

Humm...

raganwald11• 14 years ago

https://github.com/jashkenas/coffee-script/issues/2552

fogus• 14 years ago

This may be the first time that I've learn any useful information (do) during one of these CoffeeScript scope battles.

run4yourlives• 14 years ago

Can we just implement Python (or anything else, really, hell I'll even take VB at this point) in the browser already and get rid of this monstrosity of a language? Please?

mistercow5• 14 years ago

Really? Python's handling of reaching into the outer scope of a function is just as confusing (although I hear it is fixed in 3000?).

Python used to be my favorite language, but I'm currently working on a project that is CoffeeScript on the client and Python on the server, so I'm getting plenty of time to compare them side by side. It would be difficult to overstate how much I prefer working with CoffeeScript.

The thing is, this scope situation, which is admittedly not as elegant as it could be, is really a rare situation to run into. If it happens to you often, it generally means that you need to give your more global variables less vague names.

jrockway• 14 years ago

Really? Python's handling of reaching into the outer scope of a function is just as confusing (although I hear it is fixed in 3000?)

Do you mean:

   try:
     foo = '42'
   except Whatever:
     raise
   print "foo is %s" % foo

If so, I really like that feature. It's much clearer to me than what I'd write in another language:

   foo = None
   try:
     foo = 42
   ...

lvh• 14 years ago

I believe you are referring to the nonlocal keyword, which means that unlike the regular case (assignment binds as locally as possible), assignment will bind where the name is bound now. (There's a third case for globals, but let's not talk about those.)

lihaoyi• 14 years ago

If we'd implement the JVM in the browser, we'd get Java as well as Jython/JRuby/Clojure/Scala almost for free.

tesseractive• 14 years ago

Given that Oracle is now going around and suing companies that put Java to a use they don't approve of (see: the Google lawsuit over Dalvik), it appears that the JVM is too IP-encumbered to be a suitable candidate for a web standard.

Edit: imagine what a failure case it would be for the web if Oracle owned the IP rights to a core web standard and actively asserted them. Yikes.

nostrademons2• 14 years ago

It's been done before:

http://pyjs.org/

comex• 14 years ago

Actually, I don't understand CoffeeScript. The example from the post doesn't even compile, using CoffeeScript 1.3.3:

    do (methods = ['remove', 'show', 'hide', 'stop']) ->
      for method in methods do ->
        Frame.prototype[method] = ->
          for element in elements do ->
            this[element][method]()

    Error: In test.coffee, Parse error on line 5: Unexpected 'OUTDENT'

grncdr• 14 years ago

I noticed that while reading it as well, as it's one of the (few) things that bugs me when writing coffeescript. It should have a 'then' between the conditions of each 'for' loop and 'do', because that is the only way to include the loop body (the 'do' statement) on the same line as the loop conditions.

   do (methods = ['remove', 'show', 'hide', 'stop']) ->
      for method in methods then do ->
        Frame.prototype[method] = ->
          for element in elements then do ->
            this[element][method]()

qu4z-2• 14 years ago

Never used coffee script, but is it missing a new-line at the end of the file?

My intuition says it's reaching the end of the file before reaching the "end-of-block" unindent characters. I mean, the tokeniser should output enough outdents to get you back to indent-level zero when it hits EOF, but maybe it's not?

jashkenas• 14 years ago

I'm afraid that this post, while well intentioned, is actually clouding the issue it's attempting to clarify.

It demonstrates that CoffeeScript's `do` feature provides a convenient way to create a new scope for particular variables (a thing only possible in JavaScript via an immediately-invoked-function, at least, until `let` arrives) ... which is true, but is also an orthogonal concern to whether or not CoffeeScript's normal mode of variable scoping is lexical.

In many of the examples in this post:

    do (foo = 'outer') ->
      do (foo = 'inner') ->

... all of the variables are local to their function, making it a moot question whether the language is dynamic or lexical. Just as in JavaScript:

    function() { 
      var foo = "outer";
      function() {
        var foo = "inner";
      }
    }

... it would make no difference if the language had lexical or dynamic scope, because there are no variables present here that would need to reach outside of their enclosing function in order to perform variable lookup.

Lexical vs. dynamic scoping only comes into play when you refer to an external variable. Whether or not that variable is or can be shadowed is beside the point. Putting parameters aside ... In JavaScript, the variable's identity is the closest "var"-declaration of that variable. In CoffeeScript, the variable's identity is simply the name of that variable, wherever it might occur in the current lexical scope. Both ways are lexical, not dynamic.

epidemian• 14 years ago

Agreed. Maybe an example of how JavaScript/CoffeeScript would behave if it had dynamic scope semantics could help:

  // In dynamically scoped JS...
  var f = function() { alert a; }
  f(); // would throw an error as expected, but...
  var g = function() {
    var a = 5;
    f(); // would now work because `a` now exists.
  } // The scope of `a` ends here though, so...
  f(); // would throw again, but if we give life to the dinamically scoped `a` again...
  var a = 6;
  f(); // now works! Printing 6 as "expected" (at least after swallowing dynamic scope).

raganwald11• 14 years ago

From the vicious flame-fest that precipitated this post:

    x = 'lexical'

    acid = ->
      alert "#{x}ly scoped"

    test = (x) ->
      acid()
  
    test('dynamic')

geraldalewis• 14 years ago

Also, there's a little issue with @raganwald's counterexample CoffeeScript code. Here's a working version:

    methods = ['remove', 'show', 'hide', 'stop']
    for method in methods 
      do (method) ->    # *see notes below
        Frame::[method] = ->
          element[method]() for element in @elements

*As @jashkenas points out, under the hood, `do` creates a new function (and thus a new scope). Invoking `do` with a parameter list (here "(method)") takes a variable from the outer scope and uses it for a parameter name within the newly created scope. So within that new function, references to `method` will not refer to the `method` variable of the loop body, but to the new function's `method` parameter. `do (method) ->` basically compiles to: `(function(method){ ... })(method)`.

See https://gist.github.com/3742581.

mortdeus• 14 years ago

Dart!

quotemstr• 14 years ago

I found the tone of this piece incredibly off-putting. The author substitutes smugness for reason. (Also, his frequent grammatical errors and "swinging dick" comments do not exactly connote a sense of maturity and experience.)

According to the article, CoffeeScript does not actually have lexical scope for non-parameter local variable assignment, which is what most people are talking about when they say "lexical scope". CoffeeScript has as much lexical scope as Emacs 23 did (after all, you could use lexical-let, right?). This article is a "holding it wrong" defense of CoffeeScript.

If the tone of this article is typical of the CoffeeScript community, I think I'll steer clear from the whole language and stick to JavaScript when I need web scripting.

raganwald11• 14 years ago

This post is not typical of the CoffeeScript community, and the flame-fest that provoked it is not typical of the JavaScript community. Amusing outliers at best.

josteink• 14 years ago

The tone of that rant tells me all I need to know about the Coffeescript community and developers. And yes, that means I'll stay clear of it.

ajanuary• 14 years ago

The argument for not introducing a 'var' keyword equivalent seems to be "Javascript's implementation sucks", completely glossing over the fact that really it's the lack of block scoping and the presence of undefined that leads to variable 'hoisting' and related issues.

CoffeeScript removes the latter, and the former is a lot easier to introduce once you have explicit variable declaration.

Seems kinda a circular argument to me.

jdonaldson• 14 years ago

I really appreciate how Haxe (which targets js) handles this situation. If you want to write js, and stick with block level scoping, it's a great option.

        var k = 1;                                                              
         var foo = function(){                                                  
            var k = 2;                                                          
            var foo = function(){                                               
                if (Math.random() > .5){                                        
                    var k = 3;                                                  
                }                                                               
                trace(k);                                                       
            };                                                                  
         }   
  [...]

("transpiles" to)

  [...]
        var k = 1;                                                                 
        var foo = function() {                                                     
                var k1 = 2;                                                        
                var foo1 = function() {                                            
                        if(Math.random() > .5) {                                   
                                var k2 = 3;                                        
                        }                                                          
                        console.log(k1);                                           
                };                                                                 
        };

Actually, you don't understand lexical scope

Related Stories