CS2 Discussion: Question: New sugars?

[GeoffreyBooth]

How do we feel about potentially adding new sugar features at this point? By “sugar” I mean a feature like ? that has no corollary in JavaScript, that CoffeeScript provides as a shorthand to make it easier to type a complicated JavaScript construction (like => and class were when they were created). If there’s a better/more proper name for such features than “sugar,” please enlighten me.

We have two recent proposals, jashkenas/coffeescript#4144 and #39, concerning new operators that are sugars. Regardless of their specific merits, how do we feel about such proposals in general? I almost feel like we should take a position of “no more sugars,” period, as a way to avoid future cases like class or ... where ECMAScript adopts our feature but then implements it in a different way. The pipe operator, in particular, is already a debated proposal in ECMAScript; I feel like adopting it in CoffeeScript before it exists in ECMAScript (if it ever appears in ECMAScript) could just set us up for trouble down the road when their implementation differs from ours.

Sugars made sense when JavaScript was static and unchanging. But now that it’s a moving target, I wonder if CoffeeScript should still be trying to innovate new language features. It sucks, I know, to make us dependent on ECMAScript for innovation and close off our community’s creativity; especially since we’re the ones who came up with many of ES2015’s best features, like =>. But do we want to continue to play that role, if it means potentially more breaking changes in the future?

[Inve1951]

I can't think of anything different than classes which they could screw up for CS. (which only happened because those can't extend each other properly)

Worst case scenario if adding more sugar would be different syntax to JS.
If some suger gets adopted by ECMA/ES then it's opt-in becomes redundant, in which case the output could be overhauled in an update and maybe the CS syntax would change in a possible 3.0.

I wouldn't miss the oportunity to make CS more pleasant and powerful just because the guys over at ECMA/ES might do something a little different. (like using backticks for template literals)

Tell me if I missed something there.

[mrmowgli]

I also think it's good to remember that CS generates javascript, it doesn't have to look like Javascript. For that matter if the way CS does it results in faster, more reliable code, then we don't even directly need to generate ES6+ code.

ES clearly stole many concepts from CS, because of that innovation. That being said, one of the reason we have so much sugar in the first place, and some of that was understanding deeply how ES actually behaved. I don't think we will really know what sugars we want to add until we see the patterns of use emerge from the new ES fixtures.

So I'm all for adding sugars that actually improve CS, especially if it results in better code. But that also means we don't really know what that will be yet.

[jcollum]

I don't think we will really know what sugars we want to add until we see the patterns of use emerge from the new ES fixtures.

Completely agree. The ? operator seems like a good example of that and it's one of my favorite things about Coffeescript.

[lydell]

I think we should not implement any new features whatsoever until the more important issues are "done":

• ES2015+ compatibility.
• ES2015+ features.
• ES2015+ output.
• Better code base.

Also, in my opinion, discussions on new stuff makes it harder to find the important stuff in this repo.

But that’s just what I think.

[GeoffreyBooth]

Agreed @lydell, but people with their pet feature can just submit a pull request that tries to add it. Features like jashkenas/coffeescript#4144. Are such PRs just going to sit open and unmerged until 2.0.0-final is out the door? Or indefinitely, until a maintainer expresses enough interest to actually check the PR for bugs?

Speaking of which, there are 36 open PRs, many of which are years old. I feel like we should clear this backlog. What’s a reasonable way to do so? I don’t feel comfortable closing pull requests unilaterally.

We could make this repo the official place for “discussion” issues, to slim down the number of open issues/PRs on the main repo.

[DomVinyard]

Sugars are great where they make sense, but the fact that we desugared && into and is emblematic of the philosophy that made coffeescript so great.

? is a great sugar, it has a metaphor in the real world that a new user can immediately internalise.

[Asc2011]

So the TC39-folks have framed us with

• classes
• the splat-operator
• fat-arrow - (thin-arrow is in discussion, too)
• and some more things to come.

Regarding the ?-operator the following proposals were or are still discussed. It seems to be a attractive target for ES2017. The good news is, that CS passed on the ternary-operator and ES stays with it. That makes it hard for them to integrate the ?-operator into the current syntax.

• Existential Operator
• Optional Chaining
• Undefined Propagation

So there is no shortage on ideas for re-naming and rebranding common stuff.
Best-case would be TC39 stays with the CS-naming and syntax -> can't and won't happen
Worst-case would be same name, spiced with a bit different syntax, just like the splat-operator -> very confusing. i doubt this will happen, 'cos the other 'parties' - or simply the people - (CS, Ruby, F#, TypeScript) which have neither word nor vote on the TC39-process, they all use the ?-operator more or less the way CS does it.
Realistic-case -> Since early proposals for introduction of a ?-operator date back four years from now - sweet nothing is gonna happen soon - it is a tie-break.

It is not easy to avoid a defensive-position, by either waiting on or adopting the ideas of TC39.
Some people here have expressed a wish for a modular design for the CS-Next-compiler. Probably smth. that involves macros. Given that it is doable, so that one could sort of configure a CS-dialect as needed. Having a older CS-codebase then leaving out yield, im-/export.
Maybe even the splat/rest/spread-double-bind would be solvable by macros ?
Maybe the pipelining of good ideas into PR's that never get merged would stop - as people would write macros that others can decide to use in their codebases or not.
I'd prefer a more flexible approach to features instead of putting fresh-ideas for new sugars in a PR-pipeline a.k.a. hiatus position.

[oeo]

I've been using iced-coffee-script for awhile, it would be nice to add some await and defer or some sugar that would allow us to write async code in a more traditional (left to right) way if we wanted to do so.

I'd also suggest allowing optional {} notation for conditional blocks or functions. it could serve as a nice organizational tool.

+1 for the existential operator, that thing is a lifesaver.

[lydell]

@tosadvisor I think you're looking for the await keyword which CoffeeScript 2 already supports.

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4940