Proposal: Top level names

[wren-lang]

Proposal: Top level names

[kmarekspartz]

👍

[edsrzf]

This seems a little weird to me from a design standpoint, but it also seems like idiomatic code would Just Work with these rules. Overall, I like it.

I wouldn't mind seeing a further distinction by saying that "top level" names cannot be reassigned. (In other words, they're like Java's final.) I don't like that class names can be reassigned. It would help people decide when to use what type of name and could be useful in certain compiler optimizations. And finally, it would resolve the naming issue. We'd just call them "constants."

It would also become difficult to have useful mutable top-level variables, which could be both good and bad. You could always work around it by putting static variables in a top-level class or similar.

[munificent]

I wouldn't mind seeing a further distinction by saying that "top level" names cannot be reassigned.

I thought about that too. I'm not deeply opposed to doing this, but I figured I'd leave this out at first in the name of minimalism. I'm trying to cut as many non-essential features as I can.

In particular, Wren doesn't have many features that exist purely on philosophical "it's easier to write maintainable code because of this" grounds. It's not that I don't like those kind of features, it's just that they don't increase the number of things a user can do, so I can sacrifice them without loss of expressiveness.

It would help people decide when to use what type of name and could be useful in certain compiler optimizations.

I don't think we'd get much optimization out of it. Before we could take advantage of this, we'd need a much more complex compiler pipeline in general. If we had that pipeline, we could automatically tell which variables never get assigned to, so it wouldn't need to be indicated in the source to begin with.

I think single-assignability is basically just for the end user.

And finally, it would resolve the naming issue. We'd just call them "constants."

There is that! :) I was thinking maybe "local" and "nonlocal" names. What do you think?

It would also become difficult to have useful mutable top-level variables, which could be both good and bad.

You can still declare lowercase names at the top level, and I think doing so will be common. It's definitely useful in the REPL and it's handy for scripts that have some top level code. The only limitation is that those lowercase top level names aren't visible inside classes. They're usable inside other imperative code at the top level.

[edsrzf]

I figured I'd leave this out at first in the name of minimalism.

That's fair.

I don't think we'd get much optimization out of it.

There are some optimizations available even in a single-pass compiler. For example, zero-overhead constants.

var PI = 3.14159

class Circle {
  circumference {
    // This line can compile exactly like:
    // return 2*3.14159*_r
    return 2*PI*_r
  }
}

This also makes it possible to constant fold the 2*PI. Although if the class is defined before the constant, none of this can happen easily, so that's a little weird.

Another example is the expression x is Num. Since the compiler knows that Num always refers to the built-in Num class (unless it's been shadowed, which the compiler would know about), it could have a special bytecode just for this type of check. (It might not be worth doing, but it becomes an option.)

[munificent]

Yeah, I guess we might be able to do constant folding. I wouldn't rule that out at some point, though I'm not sure if it's worth the effort. We could only constant fold trivial expressions involving known operations primitive types.

In the rare places where that is a bottleneck, it's easy for the user to just do that manually:

var TWO_PI = PI * 2

Not that I'm advocating making the user manually do microoptimizations like this. But if it's a reasonably simple thing that the user can handle at their end, I think it's reasonable to keep the language simpler. :)