Write a version using ES-style spec language

[domenic]

Inspired by #44 (comment) I think it'd be a fun exercise to create a second version of the spec that is written in the obtuse-but-specific style of the ECMAScript spec itself.

This seems likely to draw out underspecified or unspecified portions, by forcing us to think more specifically about the exact language operations going on.

Feel free to close if you think this shoudn't be part of the A+ effort per se, but instead a fun side project that I do on my own time.

[juandopazo]

The thing with the ES-style is that it specs algorithms. In contrast, the current promises spec only determines an API and certain behaviors of that API. If you want different promise libraries to have the same underlying implementation (or at least very very similar), then we should write the algorithm specification.

IMO, I think the goal should be a common then+resolver implementation. Promises libraries should be allowed free range around methods other than then, but the algorithm for then should be fully specified.

[briancavalier]

Yeah, you have a strange definition of "fun" ;)

So far, I haven't felt any need to go beyond pre/post conditions, invariants, etc. for .then(). One case where that's become tricky is when a handler returns a promise.

That said, Going through the exercise of doing an ES-style version of the spec might be useful in revealing some things about the current version that we want to adjust. My worry is that we'll get sucked into re-writing the whole spec in ES-spec language, and that will make it much less approachable.

So, if you want to go through the exercise for fun and also look for ways it might inform the current spec, go for it and post interesting stuff you learn here.

[domenic]

@briancavalier yeah that was exactly my plan. I like the approachability of the current spec and have no intentions of changing it!

[domenic]

Meh this belongs in my personal tasks list, not in the issues list for this repo. Closing.