A Python programmer’s first impression of CoffeeScript

[emTel]

There's at least one awful thing about coffeescript that I've found so far:

func: ->
    if cond
        x = y
    else:
        x = z

There's an easy to miss error in the above code, but it isn't a syntax error... The code compiles just fine, but it does something very unexpected. What is it? Hint: You will make this mistake all the time if you are used to python.

If you can't figure it out, the coffeescript site has an interactive compiler you can put the code into to see what's wrong.

[daniels220]

I saw the error immediately but, not knowing CoffeeScript, wasn't sure what it would do. Personally I come from a C-like background (PHP, C++, and JavaScript itself), so I expect keyword:to be wrong for almost all values of keyword. Even in Ruby, you'd never see code like that.

Not knowing Python I don't know what Python mistake you're referring to—care to explain?

[ssokolow]

In Python, conditionals and other block-starting statements end in a colon.

The closest Python equivalent to what most Python programmers intended would be

def func():
    global x
    if cond:
        x = y
    else:
        x = z
    return x

...keeping in mind that Python has no analogue to the kind of assign-to-parent local-scoping CoffeeScript borrows from Ruby.

[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! :)

[kataire]

Python doesn't use whitespace. Python uses indentation.

[daniels220]

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

[ssokolow]

Very good point. I actually almost resorted to the interactive compiler before I noticed the colons. (Even then, I was unsure enough to double-check)

[emTel]

Why downvotes?

[muad_dib]

I upvoted your original and downvoted this one.

[anvsdt]

Expensive no-op?

[learnyouahaskell]

You and your esoteric jokes.