promises module

[Julien Viet]

Hi,

Stephane and I discussed a bit about the promises module and that it should now be imported in the SDK and there are a few concerns to discuss. One aspect is tied to the runtime Java or JavaScript that don’t have the same notion of threading that implies to have specific extension API for Java.

Should we have a complete API in ceylon.promises and the specific Java extension will be disabled in JavaScript implementation. Or should we have specific modules ceylon.promises.common and ceylon.promises.java ?

At the moment the module is only implemented for the Java backend in the ceylon.promises module itself.

any comment ?

--
Julien Viet
www.julienviet.com

[Gavin King]

What extra APIs are available for Java?

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
> To post to this group, send email to ceylo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-dev.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53a97b00.643c9869.a4%40juliens-mbp-2.
> For more options, visit https://groups.google.com/d/optout.

[Stephane Epardaud]

I would put it in the SDK especially if we plan on using them in other SDK modules. As for the name, well, it's unfortunate that we've already allocated ceylon.promises so we can't add ceylon.promises.common and ceylon.promises.java, but at the same time, our SDK modules are singular, so we should add ceylon.promise.common and ceylon.promise.java ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/4578B9D5-441F-4629-8347-D621FCDC856B%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Stéphane Épardaud

[Julien Viet]

At least one can choose to compose asynchronously or not (see java.util.concurrent.CompletableFuture).

Then there is the question of Java interrop: Java CompletableFuture <-> Ceylon Promise
The same for JS: JS Promise <-> Ceylon Promise

--
Julien Viet
www.julienviet.com

On 24 Jun 2014 at 15:58:32, Gavin King (gavin...@gmail.com) wrote:
> What extra APIs are available for Java?
>
> Sent from my iPhone
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/4578B9D5-441F-4629-8347-D621FCDC856B%40gmail.com.

[Gavin King]

P.S. It should definitely be part of the SDK.

Sent from my iPhone

[Gavin King]

You don't have that choice in JS?

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53a986e7.19495cff.a4%40juliens-mbp-2.

[Gavin King]

Isn't synchronous composition a special sort of asynchronous composition? It just adds semantics, doesn't it?

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53a986e7.19495cff.a4%40juliens-mbp-2.

[Julien Viet]

I don’t know, I just know that in JS you do

var deferred = Deferred();
deferred.fulfil(3);
promise.then(f);

f will be executed asynchronously

in Java you can chose between asynchronous or synchronous.

--
Julien Viet
www.julienviet.com

On 24 Jun 2014 at 16:19:09, Gavin King (gavin...@gmail.com) wrote:
> Isn't synchronous composition a special sort of asynchronous composition? It just
> adds semantics, doesn't it?
>
> Sent from my iPhone
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/1612BAA1-D696-4939-BA4A-5091CC29F6B2%40gmail.com.

[Tako Schotanus]

First of all I think we should use the term "core", in general, if we talk about the required part of a set of modules. Meaning that if there are several modules but there is one main part that can be used stand-alone we should call it "core". Other modules would be "extensions" that add specific functionality.

We then use "common" for those modules that cannot be used stand-alone and are normally used by more than one other module.

Second, I think this shows a situation, maybe even a "problem", that will happen many more times in the future. Somebody starts out small with project "foo.bar" but when the project becomes bigger they really want to split that into "foo.bar.baz" and "foo.bar.bag".

And maybe "foo.bar" is a domain that was bought so that can't be changed anymore. Seems harsh to say that you'll have to live with that and that it can't be changed anymore. Ever.

Don't know what the solution could be, but it seems worth thinking about, doesn't it?

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53a98a51.625558ec.a4%40juliens-mbp-2.

[Gavin King]

Wait I don't follow. Surely it's *possible* to execute a promise
synchronously in JavaScript!

On Tue, Jun 24, 2014 at 4:25 PM, Julien Viet <jul...@julienviet.com> wrote:

--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Gavin King]

On Tue, Jun 24, 2014 at 5:00 PM, Tako Schotanus <ta...@codejive.org> wrote:

> Second, I think this shows a situation, maybe even a "problem", that will
> happen many more times in the future. Somebody starts out small with project
> "foo.bar" but when the project becomes bigger they really want to split that
> into "foo.bar.baz" and "foo.bar.bag".
>
> And maybe "foo.bar" is a domain that was bought so that can't be changed
> anymore. Seems harsh to say that you'll have to live with that and that it
> can't be changed anymore. Ever.

Well that's why there's an ancient TODO asking about this issue in
§9.3.1 of the spec. But I have never got any feedback about it.

The suggested solution there is to use foo.bar_baz.

[Tom Bentley]

> Second, I think this shows a situation, maybe even a "problem", that will
> happen many more times in the future. Somebody starts out small with project
> "foo.bar" but when the project becomes bigger they really want to split that
> into "foo.bar.baz" and "foo.bar.bag".

I've never really thought of that as a problem, or rather not a problem that isn't adequately solved using versions. You have foo.bar version 1.2.3 and you release foo.bar.baz and foo.bar.bag version 2.0.0. I suppose this kind of module splitting might not be supported very well by tools, but surely that's soluble (mostly by prefix rather than exact match searches) if it's even a problem.

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCeAtvx-5gaS2D%2BT3aurH_nPWCyGRjenQzFHUs2n%2BmBH1A%40mail.gmail.com.

[Gavin King]

You might be right.

> https://groups.google.com/d/msgid/ceylon-dev/CAMd5Ysx%3DiQgupkjGUtMzOyDRKwThHQ-i8cM9Fbdpcr%2BnB%2BJWJA%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Tako Schotanus]

On Tue, Jun 24, 2014 at 5:05 PM, Gavin King <gavin...@gmail.com> wrote:

The suggested solution there is to use foo.bar_baz.

But wouldn't that be a different domain? Which you'd have to register separately?

Or is it "trick" where we (given the fact that domain names can't contain underscores) assume foo.bar_xxx to be part of foo.bar namespace?

It's a solution, but it seems a bit... icky

I was thinking that we could say that as long as they're different version the layout of modules and sub-modules could be changed (you could have "foo.bar/1.0" and "foo.bar.baz/2.0"), but of course it might be difficult to enforce or determine that distinction.

-Tako

[Stephane Epardaud]

Remember we decided to forbid submodules so you can't have a.b and a.b.c in Herd. This is something we talked about as far back as Barcelona and thought of requiring at least three parts. Herd now requires at least two.

--

You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvpbjL7RLbBWA5aZ9bSG9EKOH4UuE%2B-7SnBjTPEvErN_rw%40mail.gmail.com.

[Julien Viet]

having this restriction removed would provide a greater flexibility for the evolution of the ecosystem.

--
Julien Viet
www.julienviet.com

On 24 Jun 2014 at 18:11:33, Stephane Epardaud (stephane...@gmail.com) wrote:
> Remember we decided to forbid submodules so you can't have a.b and a.b.c in
> Herd. This is something we talked about as far back as Barcelona and
> thought of requiring at least three parts. Herd now requires at least two.

> On 24 Jun 2014 17:15, "Tako Schotanus" wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAKU9E9uaOxWGi8dSh91fDyqAaodvpabK20tBzSNEaMA91U%2BtVA%40mail.gmail.com.

[Tako Schotanus]

On Tue, Jun 24, 2014 at 5:12 PM, Tom Bentley <tom.b...@cantab.net> wrote:

I've never really thought of that as a problem

Well I call it a problem because right now we prohibit having modules a.b.X once you created a module a.b

Once we allow that the rest are "technicalities".

-Tako

[Stephane Epardaud]

Well it would open the door to the same package in multiple modules.

--

You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvrx3dcHbqG%2BqCtC7URhtt1m%2BFcS21PnfnL9rGArVin6Qg%40mail.gmail.com.

[Julien Viet]

can’t this be solved by enforcing the rule for given version of a module ?

--
Julien Viet
www.julienviet.com

On 24 Jun 2014 at 19:05:21, Stephane Epardaud (stephane...@gmail.com) wrote:
> Well it would open the door to the same package in multiple modules.

> On 24 Jun 2014 18:26, "Tako Schotanus" wrote:
>
> >
> > On Tue, Jun 24, 2014 at 5:12 PM, Tom Bentley

> > wrote:
> >
> >> I've never really thought of that as a problem
> >
> >
> > Well I call it a problem because right now we prohibit having modules
> > a.b.X once you created a module a.b
> > Once we allow that the rest are "technicalities".
> >
> >
> > -Tako
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ceylon-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ceylon-dev+...@googlegroups.com.
> > To post to this group, send email to ceylo...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/ceylon-dev.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/ceylon-dev/CAOJRyvrx3dcHbqG%2BqCtC7URhtt1m%2BFcS21PnfnL9rGArVin6Qg%40mail.gmail.com
> >
> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "ceylon-dev"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
> To post to this group, send email to ceylo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-dev.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAKU9E9t5R3LAEufzJ1ssAQPrsS_x_WauZvHHpVkc_iDG2dFO0A%40mail.gmail.com.

[Gavin King]

Unclear. How do you identify that it is the "same" module if it's name is different?

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53a9c777.4db127f8.a4%40juliens-mbp-2.

[Julien Viet]

I was meaning based on module identifier prefixes and enforced by the repository:

if a repository contains the a.b module with the a.b.c package, then the import of module a.b.c is refused by this repository.

--
Julien Viet
www.julienviet.com

On 25 Jun 2014 at 08:31:16, Gavin King (gavin...@gmail.com) wrote:
> Unclear. How do you identify that it is the "same" module if it's name is different?
>
> Sent from my iPhone
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/A6A42E41-83CA-4EE8-817E-40E761F4353E%40gmail.com.

[Julien Viet]

> You don't have that choice in JS? 

Promises/A+ (part of the next EcmaScript) says it has to be asynchronous (next tick in node.js).

--
Julien Viet
www.julienviet.com

[Stephane Epardaud]

Asynchronous in the sense of event-loops. That is: concurrent, but not parellel.

On 25 June 2014 13:55, Julien Viet <jul...@julienviet.com> wrote:

> You don't have that choice in JS? 

Promises/A+ (part of the next EcmaScript) says it has to be asynchronous (next tick in node.js).

--
Julien Viet
www.julienviet.com

On 24 Jun 2014 at 16:18:08, Gavin King (gavin...@gmail.com) wrote:
> > You don't have that choice in JS?

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/etPan.53aab899.6b68079a.a4%40juliens-mbp-2.

For more options, visit https://groups.google.com/d/optout.

--
Stéphane Épardaud

[Gavin King]

But I don't see why our APIs have to limit them selves to the
facilities of a different JavaScript API. No problem with taking that
as _inspiration_, but I don't see why it should impose an upper bound.

On Wed, Jun 25, 2014 at 1:55 PM, Julien Viet <jul...@julienviet.com> wrote:
>> You don't have that choice in JS?
>
> Promises/A+ (part of the next EcmaScript) says it has to be asynchronous (next tick in node.js).
>
> --
> Julien Viet
> www.julienviet.com
>
>
> On 24 Jun 2014 at 16:18:08, Gavin King (gavin...@gmail.com) wrote:
>> > You don't have that choice in JS?
>

[Julien Viet]

The module is now part of the SDK.

--
Julien Viet
www.julienviet.com

On 25 Jun 2014 at 14:43:53, Gavin King (gavin...@gmail.com) wrote:
> But I don't see why our APIs have to limit them selves to the
> facilities of a different JavaScript API. No problem with taking that
> as _inspiration_, but I don't see why it should impose an upper bound.
>