Update implementations.md

[vietj]

Added the Ceylon implementation of the Promises/A+ specification.

[briancavalier]

Looks pretty interesting, @vietj! Quick question: In the README it says:

the then must return before onFulfilled or onRejected is called is not implemented, therefore the invocation occurs inside the invocation of then.

This is a pretty critical part of Promises/A+. I'm not familiar with Ceylon, so I'm wondering if there is a way to schedule asynchronous tasks, so that your implementation could meet this requirement?

[vietj]

At the moment it is not yet very clear if that requirement should be met or not by the Promise implementation or by the code creating the Deferred and returning the Promise.

In the current context, this code is running in the Java Virtual Machine that is concurrent by default. So for the moment using a synchronous execution in in case the Promise was already resolved is not something that could create a technical issue like in a Node.js server.

However, I will certainly revisit this part later when more use case arise and there may be an integration point between the Ceylon Promise implementation and the runtime (the server using it) for performing an asynchronous execution.

If that happens I'll let you know and this implementation could be labelled as matching the exact semantics of the spec.

[briancavalier]

Ah, ok, thanks for the explanation, @vietj. I didn't realize Ceylon was a JVM-based, multithreaded environment. Looks like a pretty interesting language.

I feel we should accept this PR, since you've clearly documented the behavior, and we already state that implementations in other languages may not meet the spec fully.

@domenic, what do you think?

[domenic]

I might be wrong, but it seems like it's purposefully not Promises/A+ compliant. In particular,

At the moment it is not yet very clear if that requirement should be met or not by the Promise implementation or by the code creating the Deferred and returning the Promise.

The spec is actually very clear that the requirement needs to be enforced by the implementation, in the face of any deferred-using/promise-creating code.

So for the moment using a synchronous execution in in case the Promise was already resolved is not something that could create a technical issue like in a Node.js server.

I think this misses the point the spec is trying to express, which is that if you are programming against a Promises/A+ implementation, code like this needs to always output 1, 2, 3:

print("1");

value deferred = Deferred<String>();
deferred.resolve("3");
deferred.promise.then_((x) => print(x));

print("2");

As such I unfortunately don't think this is a Promises/A+ implementation, but instead perhaps a Promises/A one.

[briancavalier]

@domenic Conceptually, I feel the same, and we need to be careful not to allow any and every promise-like implementation to be listed there. However, we also say this in the "In Other Languages" section:

Although these don't necessarily match the exact semantics of the spec due to differing language capabilities

So, if we can't accept this PR, we may need to change that statement.

[domenic]

I think that statement is still accurate. This implementation does not have a mismatch due to differing language capabilities; it has a mismatch due to deliberate design choice. (At least, that's my understanding.)

[briancavalier]

This implementation does not have a mismatch due to differing language capabilities; it has a mismatch due to deliberate design choice.

Good point, @domenic. That seems like a reasonable distinction, and I think you're right that the last bit of our current language seems to fit appropriately:

due to differing language capabilities

@vietj, I agree with @domenic's points. It seems that Ceylon has access to language facilities that allow it to guarantee handlers are always invoked asynchronously. Since you mentioned that you're open to modifying your implementation, I think we could accept your PR once that happens.

[domenic]

Closing, since there doesn't seem to be any movement on this.