CS2 Discussion: Project: Project Goals

[coffeescriptbot]

From @kirly-af on 2016-08-05 13:21

We are struggling to know what we want for this project. This is discussed in different issues and I thought we should make a dedicated issue.

The way I see the project is:

1. we integrate the core features/breaking changes defined in CS2 Discussion: Project: Core Features coffeescript6/discuss#8 (those marked Tier 1, and ideally Tier 1A), enabling us to produce ES6+ output (until that stage, this could be simple PR to the original CS repo as @rattrayalex said).
2. once we have this sane basis, to me we should make this project be the CoffeeScript Babel: plugable (CS2 Discussion: Project: Make it extensible or pluggable coffeescript6/discuss#4), with new features implemented as plugins.

Then we need to think how to make the new features be introduced in the language. We have no tc39 to decide what will be standard and what will not.

I guess the ESx proposals should be core plugins that we would integrate in the compiler once standardized (of course I'm talking about those that would need modifications in the CS compiler to work).

The question is: what should we do with independent feature ideas ? The list of feature ideas is growing (see coffeescript6/discuss#16), so we definitely need to define a process to review those ideas.

I think we could adopt the tc39 process. For that, we would need a fixed list of legitimate people to discuss the proposals (+ possibly some people from the community ?).

Any thoughts ?

[coffeescriptbot]

From @rattrayalex on 2016-08-05 16:09

Thanks for opening this @kirly-af . Well framed and well said. I think the timing is right as well.

I personally certainly agree with aim 1. I hope to put together a PR in the next couple days that summarizes that and integrates it into the Readme.

As for 2, I like the babel-style, pluggable-coffeescript idea for developing and testing features, but I think we need more thought and discussion around that. I'd feel comfortable leaning on that as a tentative path forward, at any rate, if there are no objections.

I'd really like maintainers of the official coffeescript repo to be the ones guiding a tc39 process, and I agree that such a process would make a lot of sense. Perhaps a few members of this community could be promoted by @jashkenas to that role, but that's up to him. I personally would not volunteer.
In any case, I'm sure such a request (both adopting the tc39 process, and installing members of this community onto a deciding committee) would be much more warmly and credibly accepted once we have sent successful PR's to jashkenas/coffeescript filling in the "Tier 1" features like import/export, classes, etc.

Thoughts?

[coffeescriptbot]

From @carlsmith on 2016-08-05 16:53

At this stage, I think preventing CoffeeScript from becoming obsolete is the only top priority. We can work on extending the language once we've assured it wont become obsolete, which is a serious concern.

I'm happy to have these conversations about language design, to try and create a resource for the future of CoffeeScript and similar languages, but the focus of any work should be an ES6 option for the official compiler. Building a whole new version of the language with novel features is a huge project that could easily be rejected by the community.

CoffeeScript developers are adding ES6 features and we can help with that too. We should just focus on doing a fork of the current code generator, make a breaking change to make classes work with ES6 properly, and then incrementally modernise the output to catch up with and then follow the latest standards.

We still don't have anyone who wants to get that started though. Someone will have to get that process rolling, take ownership for the project long term, and lead development, else it's never going to take off or it won't accepted into the official codebase.

[coffeescriptbot]

From @MemoryChips on 2016-08-05 17:25

I agree targeting an ES6 should be the goal.

In addition, I think coffeescript was a great success because it had effectively a BDF. Without a dictator, you will end up with too many distractions. All of which are usually very good but you have to choose or nothing will get accomplished.
Rob

[coffeescriptbot]

From @objectkit on 2016-08-05 19:13

Hi all, its really good to see this thread here! Personally, I've found it difficult to understand and keep to the flow of this discussion so far as its so multidirectional, partly due to my own noise and difficulty interpreting the flow of discussions, so good call @kirly-af! I'd like to see some kind of formal process or agreed set of commitments to establish a sane basis of progress soon enough.

For whatever its worth, I'm in total agreement with aims 1, 2 and 3, but perhaps not in that order of execution.

In an ideal world, is the following high level path plausible? Could we collectively agree to

• research and pick an established third party open source general purpose parser/lexer/compiler
• define the official CoffeeScript specification as-is with a formal grammar compatible with the compiler
• choose an output language by picking an interoperable transpiler mechanism compatible with the compiler ('make it pluggable')
• decouple new CS language specifications and the development of them from ES as much as is realistically possible

Ideally, if the above is possible, when a new CS language specification is produced, and a compiler or family of compilers in place, we will still end up with choice of input language (CS1, 2, 3, 4...), and choice of output language (ES4, 5, 6, ASM...).

It would make sense in that context to most definitely pick ES6 as one of possibly many destination languages in a loosely coupled way. Who knows, by the time we agree on CS 2 (!!), ES7 may be a very viable destination language, but ES6/5/4 would still be there if desired.

To my eye, a path like that could help us reach aims 1, 2 and 3.

Apologies if I've annoyed anyone by saying that. My intention is purely for love of CS and I am really quite passionate about wanting to see it continue to grow as a language in its own right, and not just a DSL, even if not in a direction I personally prefer.

Namaste!

[coffeescriptbot]

From @carlsmith on 2016-08-05 19:28

By ES6 support, we mean ES7 once that is more widely supported, and so on. It's just that the current compiler was designed in an era where we wrote cross-browser code by hand, and we now want to generate the latest JS, and leave polyfills to other tools.

Building a whole new extensible compiler from scratch is a huge project, that will probably never become a drop in replacement for the current compiler, so will remain unlikely to be adopted.

If you want the lowest hanging fruit and a high probability of adoption, reusing the official frontend, ensures continuity and compatibility with the official language without a big fork dividing the already diminished community.

[coffeescriptbot]

From @objectkit on 2016-08-05 19:58

@carlsmith I hear you and understand your perspective- leaving polyfills to other tools, and outputting to ES6 for that purpose makes sense. Never doubted that. Fully aware. As I am technically a dinosaur with firsthand experience of NetScapes LiveScript as a young teenager, I'm well used to its difficulties and hurdles. I'm not suggesting building a whole new compiler from scratch, just to research whats out there as an alternative to CoffeeScripts current compiler and to consider using a new formal grammar representation as a result. There is a difference between a language specification and its compiler as we know. At present, they are tightly bound in the world of CS, which I perceive to be one of the hurdles for its continuation. Unfortunately I suspect that building on the current compiler will only continuate that hurdle.

If there was adoption of a new compiler from CS official after research and proof of concept, I imagine the uptake would be ok as it would permit the language to evolve, rather than diversify into dialects which is the current hazard.

So for the record, I hope the CS community that still exists is there for the language and wouldn't balk at a newly appropriated compiler (not built from scratch) that could understand a formal grammar representation of CoffeeScript 1, from which its AST could be transpiled, even solely to ES6 for sake of making it available as an input to Babel today.

I guess thats the fork in the road right there.

[coffeescriptbot]

From @carlsmith on 2016-08-05 20:09

If a new compiler was more realistic, it'd be different, but having seen Redux fail to pick up users, when its goal was to replace CoffeeScript with a compiler that targets the estree AST format, it seems better to not aim so high this time if we can avoid it. I'm not against a new parser project, but want to try and push for the most doable solution to the main issue. It's not that you don't make a lot of good points, but it seems best to keep things as simple as possible for now.

[coffeescriptbot]

From @objectkit on 2016-08-05 20:43

Hey... I think we have the roughly the same objective - attempting to lend our time to the preservation of the language and its evolution in an organised linear fashion for the benefit of many - I'm just not convinced that repurposing the current CS compiler will have long term benefit or that it is necessarily a de facto simpler path forward. No doubts it will get you there eventually, but I suspect it will incur its own difficulties as there isn't enough decoupling between the language specification and the present compiler. To cut to the chase, I believe attempting to

(a) define a new informal language specification, CS6, to suit
(b) the constraints of a preexisting DSL specific compiler derived by forking CS, while
(c) committing to one output language, ES6,

in one go... as a one off end in itself, yes, I think you'll get there, but the cost is high and the constraints uncertain.

I don't see simplicity in that. And I haven't done my homework sufficiently either! That is, there isn't a decided upon research proposal to investigate the feasibility of appropriating a general purpose compiler, so my hands are in the air, I only (strongly) suspect that as a plausible direction with long term benefits. But I'm thinking purely in terms of the language here from a research perspective, not project user acquisition. Perhaps that again is another fork in the road. Best of luck Carl. I think you'll get there.

edit: I'm being sincere, no undertones - the route you are planning is probably achievable - pax :)

[coffeescriptbot]

From @zeekay on 2016-08-05 22:26

Rather than build a new compiler I'd focus on creating a parser that can be swapped in for Babel's parser, Babylon. You could use Redux or decaffeinate's parser as a starting point and update it to output the Babel AST (which is based on the ESTree spec).

Focusing on just the parser part of the compiler stack makes a lot of sense to me -- less to build and maintain. As a bonus it would make it possible for CoffeeScript to easily interoperate with the existing Babel ecosystem and ensure adoption of new features is rapid.

[coffeescriptbot]

From @carlsmith on 2016-08-06 00:59

Doing a new parser is interesting, but my concern would be that it'll not be compatible with the official compiler, so you'll have another dialect that can't be used as a drop in replacement for parsing existing code bases. Will anyone use it? Maybe. If you do a good job of it, then perhaps, but building an ES6 code generator for the official compiler that is selectable with a flag would be much more likely to solve the core problem.

The advantages of Babel are not lost. We can write a transformer that walks an official CoffeeScript AST and generates one for Babel or whatever we need. We're doing our own code generator, but can reuse any of the existing parsers to generate our AST. Using the official one will be least likely to cause division, as people will only have to update their classes to move a module to the new compiler.

[coffeescriptbot]

From @zeekay on 2016-08-06 01:38

I do agree it's a good idea to re-use an existing compiler/parser, but I think we should target the Babel AST. Code generation is best handled by Babel. This will enable more granular control over the code generated (Babel does this very well), faster compilation, easier adoption of new features, etc.

[coffeescriptbot]

From @rattrayalex on 2016-08-06 21:49

CoffeeScript developers are adding ES6 features and we can help with that too. We should just focus on doing a fork of the current code generator, make a breaking change to make classes work with ES6 properly, and then ... catch up with ... the latest standards.

Yes.

This issue was opened asking for project direction. Here's the project direction.

First, we're going to focus – as individuals, or as a team – on getting ES6 modules (import/export) and classes into jashkenas/coffeescript.

@GeoffreyBooth and @JimPanic have been collaborating on the former here and have welcomed others to join. I'm not aware of a leading effort for classes; please post one on the relevant thread.

Once that's complete, we can consider doing the same with async/await and const, if @jashkenas is interested in the suggestions there (-> for async, <- for await and := for const), and any other similar features.

Other than that, I think anything interesting is going to take strong, opinionated leadership and probably breaking changes. I'm not willing to provide that myself, nor am I comfortable appointing someone.

As such, I propose the following process:

1. Anyone interested in leading a new "CSNext" effort submit a proposal as a PR to this repo. This will be a markdown file in a proposals directory.
2. I'll evaluate it for clarity (not whether I think it's a good idea), merge it, and create a new repo for them under the coffeescript6 org. I'll also link to each repo from the main README here.
3. We can continue to use this repo and the csnext gitter for discussions about the future of coffeescript.

An effort can take the form of a completely new language inspired by CoffeeScript, a fork of jashkenas/coffeescript, a fork of coffeescriptredux, a from-scratch Babylon/Babel CoffeeScript parser, or whatever.

There are a lot of great ideas floating around this repo and I think it's time we put a few to the test.

I'll be submitting a PR shortly that adds this to the repo and creates a proposals directory, and will update this comment with a link when that's done. Until then, I'd love thoughts and feedback!

[coffeescriptbot]

From @carlsmith on 2016-08-06 22:28

As you know though, I don't think that's the best plan. Adding classes to the original compiler will not work the same way as the other features, because classes break BC. If we just incrementally add features to the original compiler, then classes will end up with their own compilation flag. I think it's better to do an ES6 code generator, and have a flag for that instead. Otherwise, we're going to keep outputting shimmed ES3 for the bulk of our code, even though that code depends on ES6.

If anyone is planning to add support for ES6 classes to the current code generator, it's no extra effort to fork the current code generator, fix classes and use the forked generator as a drop in replacement for the current one. Then, over time, we can all incrementally modernise the new generator. With the current plan, there will not be a new generator to contribute to.

I'm not willing to take long-term responsibility for the project, but still want to encourage whoever does eventually look into fixing classes to not overlook a totally costless, golden opportunity.

[coffeescriptbot]

From @rattrayalex on 2016-08-06 22:32

I think it's better to do an ES6 code generator, and have a flag for that instead

Go ahead and propose it 😉

Thoughts on the details about how classes should be implemented (eg; whether they compile to ES6 classes, or something else, whether they use a command line flag or a major version bump, etc) should be discussed on the relevant thread – or, better yet, on a PR.

We've been talking a lot. It's time to code.