CS2 Discussion: Question: Is conflating null and undefined a feature of CoffeeScript?

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-19 07:15

In CoffeeScript 1.x, null and undefined are often interchangeable:

• if foo? returns false whether foo is null or whether foo is undefined.
• ((a = 1) -> a)(null) and ((a = 1) -> a)(undefined) both return 1.

In ES2015, at least regarding default function parameters, null and undefined are not interchangeable:

• (function (a = 1) { return a; })(null) returns null.
• (function (a = 1) { return a; })(undefined) returns 1.

This has sparked a discussion in the PR where I’m trying to implement arrow functions (and by extension, ES-style default parameters) for CoffeeScript 2. Basically, if we want to preserve the current behavior where the default value is applied when a parameter is null or undefined, we need to keep the current generated output:

f = function(a) {
  if (a == null) {
    a = 1;
  }
  return a;
}

So if we want output like this:

f = function(a = 1) {
  return a;
};

Then we have to break backward compatibility and go with ES’ implementation of default parameter values applying only when the parameter is undefined, not null or undefined. We can’t do both (the default value and the null if block) because the default value could be a function call, for example f = (a = b()) -> a.

CoffeeScript 2 was going to break backward compatibility anyway, but we want to break as little as possible. Is this null/undefined interchangeability something that people value in CoffeeScript 1.x, or would you not miss it if it went away? How important is it that the generated JavaScript for a feature like default function parameters be as ES-like as possible?

[coffeescriptbot]

From @lydell on 2016-10-19 07:55

In VimFx (~5k lines of CoffeeScript), undefined is never used as a literal – only null. If CoffeeScript were to break backwards compatibility regarding parameter defaults, I'd have to go through every function with parameter defaults (and all places the call those functions) and double-check all values that can possibly be null (to see if I need to change to undefined somewhere, which I most likely need to do in most cases). Being a crazy refactoring maniac, that wouldn't bother me personally very much though (other than a few regression bugs).

But for ? I think it really makes sense to check both null and undefined, because, to me, the point of using ? in the following code is to avoid exceptions: element?.getAttribute?('foo').

It would be nice to hear @jashkenas’ wisdom on this as well.

Is parameter defaults behaving different in CoffeeScript compared to ES a relief or a point of confusion for new CoffeeScript users? What about already experienced users?

[coffeescriptbot]

From @triskweline on 2016-10-19 08:01

While null and undefined are sometimes interchangeable, they often are not. E.g. == doesn't conflate these (and it should never do). It's OK to decide this on a per-case basis.

Conflate for existential foo? => I think that 's a very handy feature to have

Conflate for default arguments => I'd much rather have the cleaner Javascript output. Note that "The compiled output is readable" is also a CS feature, it says so right on the homepage!

In the PR discussion, I get @lydell saying that he doesn't care about the difference, got into the habbit of using null, and is now tripped up by ES semantics. I don't care either most of the time, but happen to default to undefined instead. That's a recommendation from Douglas Crockford in Javascript - The Better Parts.

[coffeescriptbot]

From @jashkenas on 2016-10-19 14:13

It's tricky. Having two slightly different values for nothing is absolutely a mistake in JavaScript, and it's something we tried to smooth over a bit in CoffeeScript my making undefined and null as interchangeable as possible.

But getting the clean output for the 2.X branch is also a desirable outcome.

I'd say that it's tragic, but go for the clean output for 2.0, and we'll live with the inconsistency.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-20 15:06

We should be keeping track of breaking changes somewhere. A wiki page on the main repo? A wiki page here? A markdown file in the project? Part of index.html in the project?

[coffeescriptbot]

From @lydell on 2016-10-20 15:19

Let’s start with a wiki page on the main repo.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-21 05:32

Wiki page here. I’ve updated #4311 to reflect this decision (assuming we’re going with ES syntax, at least for now).

[coffeescriptbot]

From @connec on 2016-10-21 17:37

Paraphrased from #4311 (wall of text incoming):

Full disclosure: I'm in the same bucket as lydell in that I've tended to use null rather than undefined, particularly as the last expression in procedures for returning an empty value. When I'm writing CS I like to live in a world where undefined does not exist.

I would rather lose ES2015's defaults and keep existence checks consistent. I really don't like the idea of defaults behaving differently to ?, ?=, etc. (though ?() gives precedent for that...). To illustrate a problem with this, currently you can use argument defaults to make values in functions 'safe' for existence checks, i.e. a default is as good as an existence check.

action = (options = {}) ->
  # We can safely call options.whatever here, since we know it's not undefined or null
  options.whatever

Admittedly this is also an issue with ES2015, but it's one that CoffeeScript solves by treating null and undefined as non-existent values, for existence checks and defaults. My issue isn't so much about allowing null as an empty argument, but more about just not having to think about the difference.

If clean output is such a desirable outcome, why not just skip CS and use ES2015? I appreciate that's a bit melodramatic, and CS adds much more value than just null/undefined unification, but it's one of the many CS features that make it so pleasingly consistent in contrast to JS' (especially ES2015's) syntax limitations and quirks.

Finally, I do feel we're being a bit flippant about changing CS semantics when there's no compatibility reason to do so, particularly when there's so much value in a release of CoffeeScript that fixes what's broken (classes) without breaking lots of backwards compatibility.

[coffeescriptbot]

From @jashkenas on 2016-10-21 17:43

Finally, I do feel we're being a bit flippant about changing CS semantics when there's no compatibility reason to do so, particularly when there's so much value in a release of CoffeeScript that fixes what's broken (classes) without breaking lots of backwards compatibility.

I agree — but I think that's basically the whole point of the current plan for "CoffeeScript 2". CoffeeScript 1 can continue to be the nice little well-tended garden that it has been ... but the point of CS2 is to embrace as much of modern JS as we can, even if that means losing some nice things that we've previously enjoyed.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-21 18:02

@connec does have a point about classes: some people might want to limit their breaking changes to “just” classes, to get the interoperability with ES classes that they need, and could care less about any other changes CS2 brings to the table. For such people it will be annoying to have to choose between 1.x’s lack of class interoperability and 2’s breaking changes that are unrelated to fixing classes.

As much as I hate to say it, we could release the classes fix as an off-by-default flag on 1.x, so that people have a way to opt-in to that breaking change without any of the others. The only other interoperability concern that 2 was planning to address was tagged template literals, but those can be implemented in 1.x too without breaking changes (whereas regular ES template literals, by contrast, need to be 2-only).

This might even be a way to thread the needle with regard to how we want to deal with classes in 2: the maximum-compatibility version, basically what @connec is working on in #4330, could be the opt-in ES-compatibility classes for 1.x; and a new implementation of classes that more closely tracks the ES spec could be what’s in 2. This sounds like a lot of work, and I’m not saying I recommend it, but it’s an option.

[coffeescriptbot]

From @jashkenas on 2016-10-21 18:14

Just for the record: I think that sort of muddled approach is the exact wrong way to go. It's already complicated, and the clarity of —

CoffeeScript 1 is the CoffeeScript you know.
CoffeeScript 2 is CoffeeScript brought as close to modern JavaScript as possible.

— is critical.

If you add a flag for classes in 1, next you're going to be adding a flag for async, and then for some sort of advanced module feature, and then another flag for ES destructuring ... and so on.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-21 18:54

I agree, but I wanted to throw it out there as an option. I suppose someone could always make a fork of CS1 plus #4330, if they really really wanted only the new classes but nothing else.

I guess the bigger question when it comes to “brought as close to modern JavaScript as possible” is, how close? We could disallow splats in function parameters that aren’t the final parameter, the way ES2015 does; that would certainly have made my PR far easier to implement. But that seemed like a pointless restriction to impose on CoffeeScript, even if that’s what ES requires.

I think we basically agreed in the other thread that prettier output alone is rarely good enough to justify a breaking change; but conforming to ES spec for parameter default values has a benefit beyond streamlined output, in that CoffeeScript would then behave more like ES2015 for people familiar with ES. It’s like if we add support for ...args in addition to args..., to make it easier for people coming from ES or going back and forth; there is some value in consistency with JavaScript, even if it means CoffeeScript itself is less internally consistent.

For the record, I think it’s worth conforming to ES on this issue at least. But I understand the complaint. Read up the thread of #4311 and you’ll see it took me some convincing as to which “old” features we were going to preserve, even if it meant outputting lots of extra JavaScript.

[coffeescriptbot]

From @connec on 2016-10-21 19:43

Apologies for another wall of text, but I'm an avid fan of CoffeeScript as it is today, and appreciate the decisions that were made in its design, particularly wrt. executable class bodies and conflating null and undefined, so here goes 😛

I feel like there's a balance of features that would satisfy people on both sides. There are plenty of features with compelling reasons to switch to ES2015:

• class is necessary to interact with ES2015 classes, which is critical for JS interoperability. If the final approach proposed in [wip] Compile classes to ES2015 #4330 is taken, the only breaking changes from this is the requirement of super calls in all derived constructors, and requiring constructors be called with new.
• Arrow functions correspond semantically to CS' fat arrow, so the handling of this can be passed to JS. This doesn't need to break anything apart from using this, though it does require different handling of parameters to deal with the absence of arguments.
• Destructuring in CS requires quite a few ref's and chained assignments, which can be cleaned up by compiling to JS destructuring. I'm a bit indifferent about this one, but it would be easy enough to adopt it without breaking any existing behaviour by continuing to do a bit of extra work around this and defaults, and it would make the common cases almost identical, syntactically.
• Dynamic object keys are a no-brainer (all gain, no pain?).
• Template literals are probably in the same category.

The main one here is definitely class, without that people literally can't use CS if they want interop with ES classes. The rest are nice-to-haves with the potential of simplifying the compiler and/or the compiled output. Regardless, I can't think of any major drawbacks for any of the above (correct me if I've missed any).

Once they are taken care of, there are other things where the main benefit is cleaner output at the cost of backwards compatibility within CS. Full class compilation, implementing splats, and default arguments would only be 'simple' if CS' semantics are changed (e.g. no more executable class bodies, no more rest before args, defaults not overriding null). These are certainly more controversial. My fundamental problem with adopting changes in this category is they take away features from the language without adding anything.

I do understand that reducing friction with ES will make CS a more compelling choice for people looking for something 'like JS, but prettier', but certainly in these cases (executable class bodies, rest args, and defaults) there would be very few surprises for users that couldn't be summed up in some short sentences:

• CoffeeScript, like Ruby, supports executable class bodies.
• Note that CoffeeScript allows splat arguments at any position in an arguments list.
• Note that CoffeeScript treats null and undefined as missing values for the purpose of default arguments, similar to the existential operators.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-22 18:31

I don’t feel strongly about this either way. The code is written for either implementation. Perhaps we need more opinions?