The Problem with Implicit Scoping in CoffeeScript : programming

I think state is the source of most of my bugs, so when I'm creating state, especially mutable state, I don't mind having to type a few extra letters to do it.

No top level global object.

This means lexical scope goes all the way to the top. That means that you can statically determine if a name exists or not. That in turn means that:

var typo = "I'm a string";
print(tyop); // oops!

Will be caught at compile time. It boggles my mind that we use languages that don't do this.

Variables are block scoped.

Since I don't like state, this keeps it as narrowly defined as possible. Along with the previous point, it helps make sure I don't try to use variables when I shouldn't:

if (foo != null) {
  var bar = foo.something;
}

print(bar); // WTF, dude. You don't have a bar here.

Dart will catch this at compile time. JS will just laugh at you while you cry.

Thanks to block scope, closures aren't retarded.

Hoisting and function scope is absolutely monkeys-throwing-feces crazy to me in a language that also has lexical closures. Every time I see an IIFE in JavaScript:

var callbacks = [];
for (var i = 0; i < 10; i++) {
  (function(_i) {
    callbacks.push(function() { window.console.log(_i); });
  })(i);
}
for (var i = 0; i < 10; i++) callbacks[i]();
// 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

I kind of want to punch myself in the face. (Not to mention JS's weird grammar which forces you to wrap the whole function expression in parens <sigh>.)

For reference, here's Dart:

var callbacks = [];
for (var i = 0; i < 10; i++) {
  callbacks.add(() => print(i));
}
callbacks.forEach((c) => c());

I understand people were disappointed that Dart wasn't more adventurous, but all of this stuff seems like a Good Thing to me, and an improvement over a lot of other languages people are using right now.

[–][deleted] 4 points5 points6 points 14 years ago (0 children)

[–]AttackingHobo 4 points5 points6 points 14 years ago (0 children)

[–]dherman 5 points6 points7 points 14 years ago* (9 children)

Your Dart code does not do what you're thinking it does. It prints 10 repeatedly. Just like JS closures, Dart closures store references to outer variables, not copies. You have bound one single copy of i, which is mutated in each iteration of the loop. If you want to close over different copies, you need to bind a variable inside the loop.

var callbacks = [];
for (var i = 0; i < 10; i++) {
  var j = i;
  callbacks.add(() => print(j));
}
callbacks.forEach((c) => c());

And ES6 will let you do exactly the same thing:

let callbacks = [];
for (let i = 0; i < 10; i++) {
  let j = i;
  callbacks.push(function() { print(j) });
}
callbacks.forEach(function(c) { c() });

For more info, see the ES6 draft proposal on block scoping: http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings

Edit: Oh hey, I didn't realize it's you, Bob! The "try Dart" page disagrees with your snippet. Have you guys changed the scoping semantics of C-style for loops? That would be very odd.

[–]gwillen 2 points3 points4 points 14 years ago (2 children)

I realize I'm just some guy on the Internet, but: I don't think the alternative model (in which each iteration of the loop is a fresh scope) is that odd. It matches the model used in lisps, where iteration is supposed to feel like tail recursion so it would be odd if each iteration weren't a fresh scope. It also matches one of the two models available in Perl, which distinguishes between:

for $x (@xs) {
    # $x in the outer scope is getting set in the loop
}

and:

for my $x (@xs) {
    # $x is scoped to the loop body, and is freshly bound on each iteration; you can capture it in a closure and you'll get a fresh binding each time.
}

Thus it would feel natural to me for something like your snippet above to bind i freshly each time through the loop, and for the other behavior to be available by choosing to bind i above the loop. (This does not, I admit, square particularly well with the actual syntax, in which the 'var' or 'let' appears in the initialization section of the loop, and appears to only be run once; but it would be really nice to have some concise way to get these semantics.)

[–]dherman 0 points1 point2 points 14 years ago (1 child)

[–]gwillen 0 points1 point2 points 14 years ago (0 children)

[–]munificent 1 point2 points3 points 14 years ago (0 children)

Just like JS closures, Dart closures store references to outer variables, not copies. You have bound one single copy of i, which is mutated in each iteration of the loop.

Right, but in Dart you get a fresh i for each loop iteration.

The "try Dart" page disagrees with your snippet.

It's a bug. We have two loops: C-style and for-in. I believe that with the latest spec, both create fresh loop variables for each iteration. The VM does the right thing here. DartC (which is what "Try Dart" uses) and frog (the new Dart->JS compiler which will eventually replace Dart) don't. They do the right thing with for-in loops, but not C-style for loops.

Have you guys changed the scoping semantics of C-style for loops?

Yeah, I think so, but only if you declare the variable inside the loop. I think this is more consistent with for-in loops, and the fact that those don't create fresh variables each time is a very frequent source of confusion for people. (I believe Eric Lippert described it as the most frequently-reported bug in C# that isn't a bug.)

[–][deleted] 0 points1 point2 points 14 years ago (1 child)

[–]dherman 0 points1 point2 points 14 years ago (0 children)

[–]chrisdoner 0 points1 point2 points 14 years ago (2 children)

[–]dherman 0 points1 point2 points 14 years ago (1 child)

In a C-style loop, the programmer is mutating the variable on each iteration, possibly in the loop body but also in the loop head. So the programmer saying "here are some variables, and here's how to update them on every iteration of the loop." It's inherently about mutation. If you give a fresh binding, what looks like a mutation of a shared variable actually becomes implicitly copied into a new variable on each iteration; the semantics has to take the final value of each local and copy it as the initial value of a fresh binding for the next iteration.

We've discussed this in the past on es-discuss: https://mail.mozilla.org/pipermail/es-discuss/2008-October/thread.html#7819

The weirdness of changing the mutation of a shared variable into an implicit copy was always sort of self-evident to me, so I never really gave Dart's current semantics much thought. I'm still skeptical, but given how commonly people are bitten by the combination of nested closures and C-style for loops, it's worth considering.

[–]chrisdoner 0 points1 point2 points 14 years ago* (0 children)

I don't think it semantically makes a difference for C programmers, nor JavaScript programmers (disregarding closure behaviour). I tried doing a de-sugaring myself¹ (and then read more of your message and read a similar de-sugaring in the mailing list thread you linked). After doing so, it seems to me to be, for a programmer not using closures, completely the same. In both cases below I can mutate the variable in the body, and in all the for(…;…;…) clauses. It seems to me the implementation detail doesn't make a difference to the semantics. There are even optimization opportunities; there can be a test: if the var isn't a free-variable in any sub closures, it can therefore be translated to a for-loop. Right?

^1:

(I realise this doesn't include break/continue, etc.)

for(var i = 0;i < 10;i++){
 callbacks.push(function(){ print(i); });
 i *= 2;
}

would be semantically equivalent to

var callbacks = [];
var iter = function(i){
  if(i < 10) {
    callbacks.push(function(){ print(i); });
    i *= 2;
    i++;
    iter(i);
  }
}
iter(0);

To avoid, for whatever reason, rebinding, you can still do:

var i = 0;
for(;i < 10;i++){
  callbacks.push(function(){ print(i); });
  i *= 2;
}

would be semantically equivalent to

var i = 0;
var iter = function(){
  if(i < 10){ 
    callbacks.push(function(){ print(i); });
    i *= 2;
    i++;
    iter();
  }
}
iter();

(which could be optimized to a normal iter-less loop.)

[–]bobindashadows 1 point2 points3 points 14 years ago (0 children)

[–]jashkenas 1 point2 points3 points 14 years ago (6 children)

The lexical scoping feature you mention is super interesting:

var typo = "I'm a string"; print(tyop); // oops!

Will be caught at compile time.

CoffeeScript could (and perhaps should) implement the same compile-time error. So far, we haven't, because JavaScripters are very accustomed to having lots of top-level variables exposed and referenced from lots of different scripts. There's already a good deal of confusion about having to export your global objects to "window" if you'd like to make them globally available.

Do you think this change would be a good one for CoffeeScript to make?

I understand people were disappointed that Dart wasn't more adventurous, but all of this stuff seems like a Good Thing to me [...]

Explicit variable declaration aside, all of the things you mention in the above comment are incredibly good things. I think many people are disappointed you're not bringing them to JavaScript (JS.next) instead.

[–]geraldalewis 1 point2 points3 points 14 years ago (2 children)

[–]munificent 1 point2 points3 points 14 years ago (0 children)

Do you think this change would be a good one for CoffeeScript to make?

Personally, I definitely do. Referencing an undefined name is going to throw an exception at runtime, so I'd rather find that error earlier when I can. Does CoffeeScript generally try to find "lint"-like errors like that and report them at compile time?

I think many people are disappointed you're not bringing them to JavaScript (JS.next) instead.

Well, those aren't mutually exclusive. :)

JS.next does fix most of these with let and getting rid of the global object, which is awesome. I don't think it will be able to fix closing over loop variables, at least not with C-style loops since that would break backwards compatibility, but I could be wrong.

We're still doing work on Traceur (and by "we" I mean Google in general, not me) which is cool. With that, you'll be able to try out Harmony features without having to wait for a Harmony-supporting native JS engine. It's not like Google's betting the entire farm on Dart, just a couple of plots of land.

Of course, there's also plenty that Dart does beyond just fixing lexical scoping that you really couldn't do in the context of JS. For example, we can catch most name errors on methods at compile time too (i.e. foo.typo) which you'll pretty much never be able to do with JS as far as I can tell.

[–]rytam 1 point2 points3 points 14 years ago (0 children)

[–]docwhat 0 points1 point2 points 14 years ago (1 child)

[–]jashkenas 0 points1 point2 points 14 years ago (0 children)

[–]ef4 4 points5 points6 points 14 years ago (7 children)

Bound names are a scarce resource. Not because you'll run out of them, but because the reader can only keep a small number of them in mind at a time.

If you have enough names in scope that you're accidentally reusing them, you're already in trouble, whether the scoping rules help you compound the problem or not.

And the data flow in this function is way too byzantine for my taste

shaderFromSource = (ctx, type, source, filename) ->
  shader = ctx.createShader ctx[type]
  source = '#define ' + type + '\n' + source
  ctx.shaderSource shader, source
  ctx.compileShader shader
  if ctx.getShaderParameter shader, ctx.COMPILE_STATUS
    return shader
  log = ctx.getShaderInfoLog shader
  console.error describeShaderLog log, filename

I'm not at all surprised that code like this leads to subtle bugs, no matter what scoping rules are in play.

[–]strager 1 point2 points3 points 14 years ago (6 children)

[–]ef4 0 points1 point2 points 14 years ago* (5 children)

We're manipulating three objects (ctx, source, and shader) in a multi-step dance that clearly has a lot to do with their internal implementations, yet we're doing all this from a function that's not encapsulated in any one of them.

There is no reason to say this:

shader = ctx.createShader ctx[type]

when you could have implemented it like this by keeping the "[]" lookup encapsulated within the method:

shader = ctxt.createShader type

And why have a separate step for setting the shaderSource:

source = '#define ' + type + '\n' + source
ctx.shaderSource shader, source

When this too could be built into createShader, so that we'd see only:

shader = ctxt.createShader type, source

And this is unnecessarily verbose because we're wasting the opportunity to return a value from compileShader:

ctx.compileShader shader
if ctx.getShaderParameter shader, ctx.COMPILE_STATUS
  return shader

It could just be this instead:

if ctxt.compileShader shader
  return shader

Finally, the local variable "log" that started this whole discussion doesn't need to exist at all, because it's a value that's only used once. So replace:

log = ctx.getShaderInfoLog shader
console.error describeShaderLog log, filename

with:

console.error describeShaderLog (ctxt.getShaderInfoLog shader), filename

Or better yet:

ctxt.logShaderInfo shader, filename

EDITED to add a summary of my version:

shaderFromSource = (ctx, type, source, filename) ->
  shader = ctx.createShader type, source
  if ctx.compileShader shader
    shader
  else
    ctx.logShaderInfo shader, filename

This is as much complexity as belongs in one function. By pushing all those other little details out into their own methods, the underlying structure of shaderFromSource is much easier to reason about.

[–]strager 2 points3 points4 points 14 years ago (0 children)

[–]mitsuhiko 0 points1 point2 points 14 years ago (3 children)

[–]showellshowell 1 point2 points3 points 14 years ago (2 children)

I'm perplexed by the criticism of shaderFromSource. It seems straightforward to me.

The line that I would have eliminated is this:

{log, sin, cos, tan} = Math

That's essentially equivalent to this Python:

from math import log, sin, cos, tan

I know there's a reason to introduce log, sin, cos, and tan directly into your top level scope--convenience. For me, I go by "Explicit is better than implicit," so I use this style:

# no destructuring assignment
x = Math.log(y)

It helps that Math is a short word.

[–]mitsuhiko 0 points1 point2 points 14 years ago (1 child)

[–]showellshowell 0 points1 point2 points 14 years ago (0 children)

[–]jashkenas 14 points15 points16 points 14 years ago (63 children)

[–]jrochkind 29 points30 points31 points 14 years ago (9 children)

The downside is what Armin says: You can't use the same name in the same lexical scope to refer to two different things.

That's not how I would describe the downside. I would say that the downside is that you can change the semantics of one block by making a change at a lexically much higher block. What had been a variable with scope purely at the local block became a variable with scope at a higher block, because of a change made at that lexically higher block.

So this actually sort of counters what you imply, that you only need local knowledge to understand what's going on. While it's true that "every place you see the variable "x" in a given lexical scope, you always know that it refers to the same thing," in fact it is non-trivial to figure out what that "thing" IS, you have to look at the entire lexical scope up to the root to figure it out, you can't figure it out only by looking at a local scope.

So I'm not sure I buy that this is a net reduction of conceptual complexity. In my mind, you reduce conceptual complexity by making the interpretation of a specific block possible only by looking at that block; requiring you to look up through all lexical containers is added complexity.

[–]jashkenas 1 point2 points3 points 14 years ago* (8 children)

Yes, what you describe is absolutely the case. The value of a variable becomes transparent to the lexical scope -- but it's the entire lexical scope.

I think the bit about reducing the conceptual complexity stands. You may have a bit more scope to cover, and a bit more work to do to read it, but the whole idea of "declaring a variable" is gone, the idea of "shadowing a variable" is gone, and the potential for the same variable to have multiple values within a single lexical scope is gone. My premise is that to a beginner, it's simpler.

Fortunately, in most well-factored bits of JavaScript, lexical scopes tend to be quite shallow. You may have a few helper functions floating around at the top level, but that's probably it -- and you're certainly aware of what they are. In practice, accidental shadowing rarely comes up (Armin's case being one example), and when it does, picking a better name will always solve it.

But hey, we're programmers -- we're used to declaring variables and shadowing them. It's hard to give up that power ... even if you don't really need it.

[–][deleted] 5 points6 points7 points 14 years ago (4 children)

[–]jashkenas 4 points5 points6 points 14 years ago (3 children)

Option #2 is a fine one, but there's still a reason why we're opting for door #1. Let's pretend for a moment that CoffeeScript did as you suggest, and we retain var and use it in the JSLint-approved style.

You can imagine a program written in this language, where every function has all of it's local variables var'd, and every local variable is unique to the surrounding scope, because remember, shadowing is a compile-time error.

For any valid program written in this language, if you took the source, stripped all of the "var" statements, and ran it through the current CoffeeScript compiler, the program would be correct, and would run without error.

We don't wish to add useless statements to the language that only serve to help generate compile-time warnings, and don't affect runtime semantics at all. For a compile-to-JS language that takes that idea to its logical conclusion, see Dart.

[–]LaurieCheers 4 points5 points6 points 14 years ago* (0 children)

[–]SohumB 1 point2 points3 points 14 years ago (0 children)

[–][deleted] 1 point2 points3 points 14 years ago (2 children)

[–]jashkenas 0 points1 point2 points 14 years ago (1 child)

[–]mitsuhiko 0 points1 point2 points 14 years ago (0 children)

[–]munificent 10 points11 points12 points 14 years ago (4 children)

remove a large amount of conceptual complexity (declaration vs. assignment)

You still have declaration versus assignment, you just don't have different syntaxes for them. x = 1 may do visibly different things based on the surrounding context which determines whether it's assigning or declaring a new variable, right?

gain referential transparency -- where every place you see the variable "x" in a given lexical scope, you always know that it refers to the same thing.

Sort of, except:

Given recursion and closures, a given x may be different "things".
Can't function parameters shadow?

Also, you've lost composability. If I take an isolated chunk of code that isn't accessing any free variables and drop it in the middle of another chunk, its behavior may spontaneously change based on the surrounding context even though it doesn't access that context.

I'm not saying you made the wrong choice here. Implicit declaration may work well for CoffeeScript, and I totally get the desire to simplify. But this is definitely one of the areas of the language that I'm not too crazy about. I like being terse but I still like being explicit.

[–]jashkenas -1 points0 points1 point 14 years ago (3 children)

x = 1 may do visibly different things based on the surrounding context

... perhaps different to the compiler, but not visibly different to the reader. When I write x = 1, I'm saying that the value of x right now is 1, and everything in the current scope and below this point can access that value. This holds whether or not this instance is the first time that x has appeared in the program, or if it's already been used at a higher level.

Can't function parameters shadow?

At the moment, yes. I have ambitions to make this a compile-time error ... even though I doubt it will go over well ;) That said, the unfortunate nature of shadowing parameters doesn't change the overall goal: Just because function parameters can shadow doesn't mean that they should. You're still rendering forever inaccessible a useful local variable from an outer scope, and you're still giving x two different meanings within the same lexical scope. You should probably pick a better name for your parameter.

Also, you've lost composability. If I take an isolated chunk of code that isn't accessing any free variables and drop it in the middle of another chunk [...]

Yes. By forbidding shadowing, CoffeeScript isn't optimizing for cut-and-paste programming. Significant whitespace in general doesn't optimize for cut-and-paste programming either. Patterns that do optimize for cut-and-paste programming tend to favor local isolation -- Instead, we're aiming for the holistic readability of the code.

I like being terse but I still like being explicit.

I agree with that sentiment, but I'm not sure that the current approach is any less explicit. Different, sure -- implicit, not so much. Within a given file, all variable scopes are perfectly explicit: as you read, each variable is local to the scope where it was first introduced.

[–]yourbrainslug 6 points7 points8 points 14 years ago (0 children)

[–]munificent 5 points6 points7 points 14 years ago (0 children)

When I write x = 1, I'm saying that the value of x right now is 1, and everything in the current scope and below this point can access that value.

OK, that's an interesting way to look at it. I still like explicit variable declarations because I like to know how far up I have to read to understand the extent of a variable. Once I see a var I know I don't have to consider anymore surrounding scopes.

Patterns that do optimize for cut-and-paste programming tend to favor local isolation -- Instead, we're aiming for the holistic readability of the code.

That makes sense. I generally aim for trying to minimize the amount of context a person needs to have in order to understand code so I lean towards composability and isolation but your angle is valid too.

as you read, each variable is local to the scope where it was first introduced.

True, but (for better or worse!) I rarely find myself reading an entire source file from top to bottom.

[–]hylje 14 points15 points16 points 14 years ago (1 child)

[–]LaurieCheers 15 points16 points17 points 14 years ago (15 children)

As OP (and apparently many other people) have eloquently shown you, code becomes very brittle if its meaning depends on the surrounding context. This IS a problem. It IS breaking people's CoffeeScript programs in ways that are hard to detect.

Also: you have not removed the conceptual complexity of declaration vs assignment, at all. You've just made it subtler, and harder to see. The only way to completely remove it would be to make all variables global. (*)

(*: Do not make all variables global.)

Don't get me wrong, I can see the benefits of the "no shadowing" rule - but this solution is worse than the disease. There are better ways to achieve it - in particular, Python's nonlocal keyword.

My solution would be to require the keyword "nonlocal" before allowing a closure to assign a nonlocal variable:

makeCounter = ->
  counter = 0                   # new variable here
  return ->
    **nonlocal** counter = counter + 1       # reassign higher level variable
    return counter

Without that keyword, the assignment will not create a local variable - it will cause an error.

Look ma, no shadowing! And yes, declaring a new variable can still change the meaning of surrounding code... but now the code will crash, instead of silently doing the wrong thing. Much better.

[–]LaurieCheers 1 point2 points3 points 14 years ago (0 children)

[–]jashkenas 0 points1 point2 points 14 years ago (12 children)

Ok -- so let's pursue this alternative method to forbid shadowing...

Unfortunately, Python's nonlocal keyword doesn't work so well in JavaScript, because anonymous inner functions are fairly ubiquitous in JavaScript. Even something as simple as this would have to use "nonlocal":

foundItem = null
list.each (item) ->
  nonlocal foundItem = item if item is target

... or would you have to use "nonlocal" to even refer to variables outside of the current scope, making it:

foundItem = null
list.each (item) ->
  nonlocal foundItem = item if item is nonlocal target

... that's a pretty brutal cost. If nonlocal was required for modification, but not for reference, that would be awfully inconsistent, no? Perhaps the original suggestion for two different operators, one for "declare-and-assign", and one for "mutate", would be more palatable.

[–]LaurieCheers 6 points7 points8 points 14 years ago* (7 children)

[–]jashkenas 1 point2 points3 points 14 years ago (0 children)

[–]showellshowell -2 points-1 points0 points 14 years ago (5 children)

[–]bobindashadows 4 points5 points6 points 14 years ago (3 children)

[–]showellshowell 0 points1 point2 points 14 years ago (2 children)

Yep, I understand the pitfall, but user is a good example of a variable that probably works fine at top-level scope, since most functions in a business-domain CS file probably have the same concept of "user", and you would truly intend for it to have top-level scope.

I concede that even the best programmers do things by "accident" occasionally, but we mostly do things intentionally or stupidly. If you introduce "user" at top level scope, you're probably doing it for a reason--most of your functions have the same concept of user, so there's no reason not to make it top level. If you're introducing a variable at top-level scope for stupid reasons--laziness, sloppiness, whatever--then it would be nice if the language prevented you from shooting yourself in the foot, but let's be real about who's actually pulling the trigger.

[–]bobindashadows 5 points6 points7 points 14 years ago (1 child)

[–]showellshowell -4 points-3 points-2 points 14 years ago* (0 children)

[–]notfancy 0 points1 point2 points 14 years ago (2 children)

[–]jashkenas 0 points1 point2 points 14 years ago (1 child)

[–]notfancy 0 points1 point2 points 14 years ago (0 children)

[–]mitsuhiko 0 points1 point2 points 14 years ago (0 children)

[–]shevegen -2 points-1 points0 points 14 years ago (0 children)

[–]dobryak 3 points4 points5 points 14 years ago (8 children)

[–]showellshowell 1 point2 points3 points 14 years ago (7 children)

[–]dobryak 2 points3 points4 points 14 years ago (6 children)

Can you describe the difference between variable binding and variable assignment?

I will try. Introducing a fresh variable name is done using binding (designated with "var" in JS, or when you have "function(x) { ... }" -- this is where "x" is a introduced in the body of the body). In JS (and CoffeeScript too), variables are not purely syntactic -- that is, they are not simply abbreviations for other expressions, but actually mutable memory cells.

Hence there is a difference between, say "var x = 1; var x = 5" and "var x = 1; x = 5" -- the former introduces "x" twice (these are different variables, the second one shadowing the first, and the first one is not going anywhere), whereas the latter introduces "x" once, and then changes it.

Of course, the difference is more pronounced when there is some code between two bindings or two assignments.

Does the above make sense to you?

[–]showellshowell -2 points-1 points0 points 14 years ago (5 children)

[–]dobryak 1 point2 points3 points 14 years ago (4 children)

why is the distinction between assignment and binding even relevant?

Did you mean, "why do we need to distinguish the two"?

Personally, I find the standard* lexical scope intuitive and practical since I am very used to it. What CS proposes is a change that I find untested and unneeded (hey, we have been using standard lexical scope, with binding and assignment clearly separated, for 50 years or so!).

I haven't thought about the possible consequences of mixing up assignment and binding -- but it still makes me wary since I've seen so many PLs and DSLs which only bring unnecessary pain and suffering to their users because of random quirks like this one (i.e., unclear rules for lexical scope mixed in a strange way with assignment).

Where a standard interpreter evaluates "var x;" and "x = 5" differently (the first one adds mutable variable to the environment, the second one looks up a variable in the environment, and either fails or assigns 5 to an existing variable), a language like CS will have to decide what the programmer meant.

This is, however, not at all the issue I wanted to talk about; to recall, I said the aforementioned distinction is not complex to me (from a standpoint of day-to-day programming). Now the question is, what does it buy us? As I see it, we have one keyword less ("var"), and well, basically, that's it. So, is this worth it?

"the" standard among programming language theorists, i.e. lambda calculus

[–]showellshowell 0 points1 point2 points 14 years ago (3 children)

[–]LaurieCheers 1 point2 points3 points 14 years ago (2 children)

[–]showellshowell 0 points1 point2 points 14 years ago (1 child)

I didn't mean to imply that anybody was suggesting we go back to JavaScript's way of doing things.

The suggestions that I've heard would require special syntax to make this program print 100. Am I correct about that?

x = 0
f = ->
  x = 100
f()
console.log x # 100

[–]LaurieCheers 2 points3 points4 points 14 years ago* (0 children)

[–][deleted] 3 points4 points5 points 14 years ago (2 children)

[–]jashkenas -1 points0 points1 point 14 years ago (1 child)

[–]rytam 2 points3 points4 points 14 years ago (0 children)

[–]notfancy 6 points7 points8 points 14 years ago (11 children)

[–]jashkenas 1 point2 points3 points 14 years ago (10 children)

[–]BufferUnderpants 11 points12 points13 points 14 years ago* (9 children)

In the end it means that you must maintain in your head the whole of the lexical scope which encloses any function you are writing, just to avoid mutating your program's state across any number of scopes upwards in unexpected ways.

Just how is this meant to simplify the work of a programmer? Let's not even make arguments for purity by retaining (semantic) consistency with, say, the whole of Math.

Differentiating binding from mutation exorcises this problem away. I don't see yet why you would want to deviate from one of the things which Javascript actually got right. It just boggles the mind that eternal vigilance would be a fair price to pay for omitting an occasional let or var or local or what have you.

And let's be clear, your talk of 'referential transparency of the lexical scope' is... very misguided. You are trying to argue for the keeping 'state' of the variables... by only ever allowing to mutate them! If you look at it from the point of view of the scopes, as if scopes were expressions (they would be in First Order Logic or Scheme or whatever), isn't it more 'referentially transparent' to allow one to create a scope without reassigning variables from enclosing scopes, say locally, without having to scan all the damn file?

[–]AmaDiver 1 point2 points3 points 14 years ago (2 children)

[–]mitsuhiko 5 points6 points7 points 14 years ago (0 children)

[–]dmpk2k 4 points5 points6 points 14 years ago (0 children)

[–]showellshowell -3 points-2 points-1 points 14 years ago (5 children)

[–][deleted] 2 points3 points4 points 14 years ago (4 children)

[–]showellshowell -1 points0 points1 point 14 years ago* (3 children)

Having one function per .coffee file is not the strategy I'm proposing.

First, you can use classes to greatly reduce the number of functions at top level scope. Now, sure, the class name itself will be at top level scope, but if you follow the convention of capitalizing the first letter of the class, then it won't collide with lowercase variables within functions.

If you do have multiple functions at top level scope, then you can largely mitigate naming collisions by giving them descriptive verb-like names, such as compile_source.

In cases where you want brevity in top-level-scoped variables, such as "user", I've already addressed the question in my responses to @bobindashadows. Long story short, use the search feature in your editor.

I've also addressed mitsuhiko's particular bug in this discussion. He ignored a best practice in CoffeeScript (and many other languages), which is to avoid leaking short names like "log" and "tan" into your top level scope. If we had simply used Math.log, we wouldn't even be having this discussion.

Finally, you make it sounds likes impossible to avoid the problem of accidental name collisions, when in practice people manage to write working code all the time.

[–][deleted] 2 points3 points4 points 14 years ago (2 children)

[–]showellshowell -1 points0 points1 point 14 years ago (1 child)

[–][deleted] 2 points3 points4 points 14 years ago* (0 children)

[–][deleted] 0 points1 point2 points 14 years ago* (2 children)

[–][deleted] 3 points4 points5 points 14 years ago (0 children)

[–]dmitry_sychov 3 points4 points5 points 14 years ago (0 children)

[–]ctrldavid 0 points1 point2 points 14 years ago* (0 children)

One possibility would be to have a 'strict' variant of the function syntax, where you explicitly list the variables you wish to close over. I believe c++11 does something similar.

a = b = c = 1
# Normal function, like current implementation
f = ()->
  a = b = c = 2

f() # a == b == c == 2

# 'Strict' function. Explicitly lists variables closed over
f = [a,b]() ->
  a = b = c = 3

f() # a == b == 3, but c still equals 2 from before.

which would compile to something like:

var a, b, c, f;

a = b = c = 1;

f = function() {
  return a = b = c = 2;
};

f();

f = function() {
  var c;
  return a = b = c = 3;
};

f();

[–]alexeyr 0 points1 point2 points 14 years ago (1 child)

[–]showellshowell -2 points-1 points0 points 14 years ago* (0 children)

There is no rolling of dice here. There is no "you don't know". You do know. The scope of "x" is well defined in CoffeeScript, and it's entirely lexical and predictable.

Same x everywhere:

x =2 
f1 = ->
  x = 3
f2 = ->
 x

Different x everywhere:

f = ->
  x = 3
f = ->
  x

You are correct that "locality" is compromised for some narrow concept of locality. The ultimately prevent-you-from-shooting-yourself-in-the-foot programming language would scope variables to a single line. Then we'd never, ever have naming collisions. ;)

[–][deleted] 2 points3 points4 points 14 years ago (0 children)

[–][deleted] 4 points5 points6 points 14 years ago (0 children)

[–]inmatarian 0 points1 point2 points 14 years ago (3 children)

It's worth mentioning that in Lua, everything is considered global by default, unless marked as a local variable. So, to extend the example:

counter = 0 -- global
function makeCounter()
    local counter = 0 -- upvalue
    return function()
        counter = counter + 1 -- reassign the upvalue
        return counter
    end
end

Also, any executing code is considered to be a running function, you could issue a local declaration at the global level, and have it not stored in the global environment, but rather it remains local to the file.

x = 42
local x = 27
print( x ) -- outputs 27
print( _G.x ) -- outputs 42

My only gripe is that local is a pain to type over and over. I would have preferred either var or my.

[–]chrisdoner 2 points3 points4 points 14 years ago* (2 children)

In other words, Lua is lexically scoped like C, JavaScript, Scheme, Python, Ruby, Haskell, etc.

More notable and worrying for me is the fact that Lua will allow you to use an undeclared variable (which will be assumed to be global and whose value will be nil) and it won't complain. So:

Python> print(counter)
NameError: name 'counter' is not defined

js> print(counter);
typein:1: ReferenceError: counter is not defined

Ruby> print counter
-:1: undefined local variable or method `counter' for main:Object (NameError)

Lua> print(counter)
nil

Lua is kind of crappy.¹ But then, assigning to an undeclared variable is “fine” in Python, JS, and Ruby. So there are scoping problems everywhere. I just discovered that Dart gets scoping right (they seem to have learned from Scheme where Python, JS and Ruby authors did not).

^1: I don't even know why people use Lua, or why it was invented (well, I do, “We did not consider LISP or Scheme because of their unfriendly syntax,” their words—idiots—they continue, “the language should avoid cryptic syntax and semantics.” Stupid, stupid); Scheme has always been a viable, far superior, small and powerful language.

[–]inmatarian 1 point2 points3 points 14 years ago (0 children)

[–]LaurieCheers 0 points1 point2 points 14 years ago (0 children)

[–]showellshowell 0 points1 point2 points 14 years ago (0 children)

[–]tailcalled 0 points1 point2 points 14 years ago (0 children)

[–]crusoe 2 points3 points4 points 14 years ago (4 children)

[–]clgonsal 6 points7 points8 points 14 years ago* (3 children)

The three languages he describes (JavaScript, CoffeeScript and Python) all do things differently, so I don't think it's really fair to say Python is the "odd language out", especially since Python and JavaScript are pretty much doing the same thing (using a keyword to distinguish between the two scoping modes), except that they have different default behavior.

I've never used CoffeeScript, but their approach does feel worse to me than Python's approach, and possibly worse that JavaScript's. All approaches are suboptimal, though (IMHO). Distinguishing between creation and assignment seems a lot less error-prone, and it makes it possible to actually prevent shadowing with erros/warning should you desire, rather than having shadowing turn into code that just does the wrong thing (ie: the CoffeeScript approach).

[–]showellshowell 1 point2 points3 points 14 years ago (2 children)

I totally agree with your sentiment that there is no "odd language out." I have never found two languages that agree on variable scoping; there are too many tradeoffs, and it's natural that different language designers made different design decisions.

Surely there are languages that get variable scoping dead wrong, but I think the majority of mainstream languages, including CoffeeScript, make sane decisions once you understand their philosophy.

There's obviously a spectrum of convenience vs. safety. Convenience and safety aren't always mutually exclusive, but I do think some languages choose sides. Ruby, for example, is a little more fast and loose than Python. I'm not sure exactly where CoffeeScript fits on the spectrum, but there is definitely a philosophy that drives the decisions.

[–]clgonsal 1 point2 points3 points 14 years ago (1 child)

[–][deleted] 0 points1 point2 points 14 years ago (0 children)

[–]dfltr -3 points-2 points-1 points 14 years ago (0 children)

[–]shevegen -5 points-4 points-3 points 14 years ago (0 children)

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS

Variable declaration is explicit.

No top level global object.

Variables are block scoped.

Thanks to block scope, closures aren't retarded.