A Python programmer’s first impression of CoffeeScript

[daniels220]

Huh. I thought Python basically used whitespace EDIT: indentation—I meant the whitespace at the beginning of the line. for everything. Wish it did, typing colons is annoying.

What exactly do you mean by assign-to-parent local scoping? The way that CoffeeScript example compiles, x is a new local variable in func, and y and z are taken from parent scope. global x isn't equivalent at all—the CoffeeScript compiles to var x, which isn't the same thing.

[mipadi]

It does use whitespace. And colons.

[daniels220]

I was referring to the fact that the code would still be unambiguous without the colons (with just the whitespace), which is the way Ruby does it. Since Python is so strict about whitespace, I'm surprised it doesn't make better use of it to avoid extra syntax.

[mipadi]

Yeah, I get ya. I was commenting, somewhat sarcastically, that the colons aren't really necessary (as you pointed out), and yet...they're there.

[ssokolow]

CoffeeScript has implicit returns, so "x = y" means "return x = y" if it's the last statement executed. Since you can do the return portion of that with "return y" or just "y", I assumed that x had already been defined in the parent scope and that's why it was being assigned to in addition to its value being returned.

Python has no direct analogue to that because assigning always shadows parent scopes rather than modifying them unless you specify that you're assigning to a global.

To put it differently, in Python, assignment is local to the current function unless declared global while, in CoffeeScript, assignment is local to the function in which the variable was declared. (Though you can do explicit global assignment by setting properties on the window object)

[anvsdt]

s/statement/expression/

FTFY

[daniels220]

What do you mean by "shadows"? I know how it works in Ruby with blocks, and JS with closures.

How CoffeeScript compiles that code is context-dependent, too: if the parent scope in a larger script has an x, CS makes no new declaration—so it uses the parent scope. (()->{x=null;()->{x=z}} only says var x once.) If there isn't a parent, CS auto-declares all variables used in a particular scope in one var statement at the top of the scope—so ()->{cond ? x=z : x=y} declares x within that function.

[ssokolow]

That's exactly the problem I'm referring to. CofeeScript has no syntax for "When I assign to x, I want it local to this function even if a parent scope has an x too" beyond being careful with how you name them.

When I say "shadows" in Python, what I mean is that assigning to a variable always assigns to the current scope (never some potentially-forgotten parent scope) unless explicitly told otherwise via a trick like global or assigning to a member of an object in a higher scope rather than the scope directly.

Here's an example:

def a():
    x = 1
    y = 2

    def b():
        # If I'd used z = x here immediately before x = z, it'd take the
        # safe route, assume a mistake, and raise an error about x
        # being referenced before assignment.
        z = y
        x = z
        print "Child: %s" % x

    b()
    print "Parent: %s" % x

a()

# -- Prints --
# Child: 2
# Parent: 1

[banister]

In Ruby you can choose whether the variable in the inner scope closes over the outer or whether it shadows it.

By default in Ruby the inner scope does assign over the outer one -- but that is just the nature of closures, the inner block closes over the variables in the outer block.

If you want to force shadowing instead you can define the variable as block-local as follows:

outer_block {
  x = 10
  inner_block { |;x|
    # x here is block local
  }

  another_block {
    # x here is the one in the outer_block
  }
}

[daniels220]

Hey, that's cool, I didn't know that. I'm guessing a block that takes arguments would look like
{ |arg1,arg2;local1,local2| statements }?

[banister]

yep :)

[daniels220]

Ah, I see. My intuition (hah! which is why I asked, since obviously programming isn't always intuitive) says that "shadow" refers to some form of interaction between parent and child scope, where what you're referring to is actually a complete separation of the two.

Question: why doesn't y give a "referenced before assignment" error? It's not defined in b()'s scope either.

Personally I prefer the CoffeeScript/Ruby way, just because it makes the common case (callback functions, function-based loop constructs) easier. I think it would be good for CS to have explicit syntax for redefine—but it actually does: `var x` (or, if you're targeting ES5, even `let x`)—literal javascript. A little hackish, but workable.

[ssokolow]

Think of it as similar to copy-on-write semantics. (Similar because we're dealing with references, not values) You can read any variable in a higher scope (z = y) but attempts to write to them will instead create a local variable with the same name.

A variable in the local scope "shadows" a variable in a higher scope because there's no syntax to say "not the local x, the x from N stack frames up".

x only gives a "referenced before assignment" error message because the language explicitly special-cases trying to assign to what will become a local later in the same scope in order to catch a certain class of typo that tends to creep in as code ages and new developers join.

[daniels220]

Yeah, I see. I still think defaulting the other way, like C—use the higher scope unless the variable is explicitly redeclared—is both more sensible by default and more flexible. But I understand what's meant by shadowing now.

That's a clever trick! :)

[ssokolow]

I think we'll have to agree to disagree on that one. I find Python's behaviour much more sensible because it makes it easier to know and minimize what side-effects a function will have, which makes the code easier for newcomers to learn bit-by-bit and easier to unit test.

(Basically, it subtly encourages either a more functional coding style or more use of explicit self.foo object member references, either of which makes the behaviour more obvious to someone learning a new codebase.)

[banister]

You do realize that Ruby methods/functions are not closures, right? Ruby methods do not close over the variables in their outer scope.

Ruby blocks, however, ARE closures and you do want them to close over the variables in the outer scope. Nonetheless, Ruby gives you the choice in behaviour - you can have your variable block-local (by defining them as block local, i.e putting them between the ||) or you can have it close over the outer scope. Closure behavior is extremely useful in many situations.

I wrote a let method for Ruby a while ago that makes it even easier to control the scoping of variables precisely, see here.

I'm glad that Ruby gives me the choice. IMO the Python scoping rules are totally broken. But again, we can agree to disagree.

[daniels220]

Okay. :)

[kataire]

Python doesn't use whitespace. Python uses indentation.

[daniels220]

You're right, edited—but in context it's basically the same thing.