Smalltalk › Amber Smalltalk

Handling async callbacks

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Kumar

Re: Handling async callbacks

This is an independent implementation of promises. Bridging over to JS apis didnt feel very smalltalkish, so I tried a separate implementation. So far I like it this way, though it looks like something on the master broke the message forwarding feature that I havent gotten around to fixing yet (but soon will).

-Kumar

On 26-Dec-2013, at 1:07 am, Manfred Kröhnert <[hidden email]> wrote:

Hi Kumar,

it seems that you are using the Promises API which is going to be implemented in ES6, right?

Recently I read the following article about the upcoming Promises support, but it wasn't clear to me if you are actually using this API:

http://www.html5rocks.com/en/tutorials/es6/promises/

What I was also wondering about is why you need methods like 'commit' or 'fullfill' (which is not in the API description I read) or why you need to handle the state of the promise yourself (which should already be handled by the ES Promise object if I understood this correctly).

Wouldn't it be easier to just create a lightweight wrapper around the original Promise object?

Best,
Manfred

On Thu, Dec 12, 2013 at 8:20 AM, Srikumar Subramanian <[hidden email]> wrote:

Hi Andy and others,

While core.async is certainly nice (check out some of swannodette's cool ClojureScript demos too), I do find promises (and family) to be useful programming conveniences when concurrency is not the primary technical muscle being brought to solving the problem at hand. Towards this, I've been working on a Promise class for Amber and would like some feedback from the amber community on it.

The package's source is in the "promise" branch of my amber fork. https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st

It is work-in-progress, but is documented enough to be useful I think (click the "Doc" checkbox in Helios). Promise is based on the Promises/A+ specification, but is more smalltalk-ish and has some smalltalk-specific goodies - ex: you can send a message to the value being promised as though it were available right away .. and the result will be a promise that will yield the return value of the message when it eventually gets sent. In other words, you can use a promise for a value pretty much as though the value were available right away.

Best,
-Kumar

On Saturday, November 23, 2013 6:51:14 PM UTC+5:30, Andy Burnett wrote:

I was just watching Rich Hickey's core async presentation (http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber.

Does amber/pharo have a queue system we can use?

Cheers
Andy

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "amber-lang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Manfred Kröhnert

Re: Handling async callbacks

On Wed, Dec 25, 2013 at 11:01 PM, Srikumar K. S. <[hidden email]> wrote:

This is an independent implementation of promises. Bridging over to JS apis didnt feel very smalltalkish, so I tried a separate implementation. So far I like it this way, though it looks like something on the master broke the message forwarding feature that I havent gotten around to fixing yet (but soon will).

But why not reuse something which will be part of the ES6 standard anyways?

We usually try to reuse existent JS libraries.

I asked because my plan is to use ES6 Promises (or polyfill [1] for now) for Amberc to make it more understandable/maintainable.

Best,

Manfred

[1] https://github.com/jakearchibald/ES6-Promises

-Kumar

On 26-Dec-2013, at 1:07 am, Manfred Kröhnert <[hidden email]> wrote:

Hi Kumar,

it seems that you are using the Promises API which is going to be implemented in ES6, right?

Recently I read the following article about the upcoming Promises support, but it wasn't clear to me if you are actually using this API:

http://www.html5rocks.com/en/tutorials/es6/promises/

What I was also wondering about is why you need methods like 'commit' or 'fullfill' (which is not in the API description I read) or why you need to handle the state of the promise yourself (which should already be handled by the ES Promise object if I understood this correctly).

Wouldn't it be easier to just create a lightweight wrapper around the original Promise object?

Best,
Manfred

On Thu, Dec 12, 2013 at 8:20 AM, Srikumar Subramanian <[hidden email]> wrote:

Hi Andy and others,

While core.async is certainly nice (check out some of swannodette's cool ClojureScript demos too), I do find promises (and family) to be useful programming conveniences when concurrency is not the primary technical muscle being brought to solving the problem at hand. Towards this, I've been working on a Promise class for Amber and would like some feedback from the amber community on it.

The package's source is in the "promise" branch of my amber fork. https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st

It is work-in-progress, but is documented enough to be useful I think (click the "Doc" checkbox in Helios). Promise is based on the Promises/A+ specification, but is more smalltalk-ish and has some smalltalk-specific goodies - ex: you can send a message to the value being promised as though it were available right away .. and the result will be a promise that will yield the return value of the message when it eventually gets sent. In other words, you can use a promise for a value pretty much as though the value were available right away.

Best,
-Kumar

On Saturday, November 23, 2013 6:51:14 PM UTC+5:30, Andy Burnett wrote:

I was just watching Rich Hickey's core async presentation (http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber.

Does amber/pharo have a queue system we can use?

Cheers
Andy

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "amber-lang" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].

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

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Kumar

Re: Handling async callbacks

But why not reuse something which will be part of the ES6 standard anyways?
We usually try to reuse existent JS libraries.

(PS: Apologies for delayed response. It's "music season" in chennai :)

I agree that in general it makes sense to do that and surely I'll align this class to match some of what's proposed in ES6. To answer the bigger question here, I'd like to step back and ask "why is it worth programming client-side in smalltalk?"

The main reason I began looking at Amber is the availability of a dev environment that I can access in a staging server and live method modification. Recently, Firefox and node-inspector have bridged that rather well. Nice stepping debugger, edit code and save on the server, etc. (Not sure about live method modifications though.)

Let's look at using an ES6 promise "p" in smalltalk. Here's how you'd have to write code to sequence actions after a promise is fulfilled.

(((p then: [blah] else: [blah])

then: [blah1] else: [blah2])

then: [blah3] else: [blah3])

This is *way* less syntactically elegant than the JS version -

p.then(blah, blah)

.then(blah1, blah1)

.then(blah2, blah2);

It has no semantic advantages over JS either. So if we do want to do this elegantly in ST (syntactically), we need something using the cascade operator. The "PromiseChain" class is for that purpose.

In ES6 "then" is the only way to access the value promised by a "Promise". However, because there is support for a "#doesNotUnderstand:", we can do something in ST that makes it simpler to use promises - we can make a promise forward messages that it doesn't know about to the value, when it becomes available. The result of sending such a message to the promise would itself be a promise. This makes for code that reads pretty synchronous. (Some problems with this, but will reserve them for later.) This degree of elegance would be impossible in JS.

A second case where this kind of thinking becomes interesting is an implementation of Channels based on promises. core-async in ClojureScript was talked about on the mailing list. Since there is no easy way to rewrite code in ST (i.e. macros), how might one go about implementing channels with a similar programming elegance as achieved in ClojureScript?

One way is to treat a channel as producing promises for values (I have a basic implementation which I'll share soon.) So you can write something like this -

c1 := Channel new.

c2 := Channel new.

c3 := Channel new.

[

x := c1 take.

y := c2 take.

c3 put: (x * x) + (y * y).

] goForever.

and it'll be perfectly asynchronous. goForever has a simple implementation -

BlockClosure>>goForever

|p|

p := self value.

p isPromise ifTrue: [p then: [self goForever]] ifFalse: [^p]

(ignoring exception handling for illustration)

This would play nicely with the #doesNotUnderstand behaviour of promises to give us go-routine kind stuff in Amber.

Again, Without a doesNotUnderstand behaviour, this level of elegance would be impossible in JS.

To summarize, when JS does get a feature like #doesNotUnderstand, given the current crop of tools, I think it would pretty much be not worth inserting another language layer like ST on top. So it makes sense to me to encourage designs that exploit doesNotUnderstand for usage elegance.

-Srikumar

On Thursday, December 26, 2013 11:27:38 PM UTC+5:30, Manfred Kröhnert wrote:

On Wed, Dec 25, 2013 at 11:01 PM, Srikumar K. S. <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">sriku...@...> wrote:

This is an independent implementation of promises. Bridging over to JS apis didnt feel very smalltalkish, so I tried a separate implementation. So far I like it this way, though it looks like something on the master broke the message forwarding feature that I havent gotten around to fixing yet (but soon will).

But why not reuse something which will be part of the ES6 standard anyways?
We usually try to reuse existent JS libraries.

I asked because my plan is to use ES6 Promises (or polyfill [1] for now) for Amberc to make it more understandable/maintainable.

Best,
Manfred

[1] <a href="https://github.com/jakearchibald/ES6-Promises" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjakearchibald%2FES6-Promises\46sa\75D\46sntz\0751\46usg\75AFQjCNFljL177--Zq3rH1YIhoh22mkPk0Q';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fjakearchibald%2FES6-Promises\46sa\75D\46sntz\0751\46usg\75AFQjCNFljL177--Zq3rH1YIhoh22mkPk0Q';return true;">https://github.com/jakearchibald/ES6-Promises

-Kumar

On 26-Dec-2013, at 1:07 am, Manfred Kröhnert <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">mkroeh...@...> wrote:

Hi Kumar,

it seems that you are using the Promises API which is going to be implemented in ES6, right?

Recently I read the following article about the upcoming Promises support, but it wasn't clear to me if you are actually using this API:

<a href="http://www.html5rocks.com/en/tutorials/es6/promises/" target="_blank" onmousedown="this.href='http://www.html5rocks.com/en/tutorials/es6/promises/';return true;" onclick="this.href='http://www.html5rocks.com/en/tutorials/es6/promises/';return true;">http://www.html5rocks.com/en/tutorials/es6/promises/

What I was also wondering about is why you need methods like 'commit' or 'fullfill' (which is not in the API description I read) or why you need to handle the state of the promise yourself (which should already be handled by the ES Promise object if I understood this correctly).

Wouldn't it be easier to just create a lightweight wrapper around the original Promise object?

Best,
Manfred

On Thu, Dec 12, 2013 at 8:20 AM, Srikumar Subramanian <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">sriku...@...> wrote:

Hi Andy and others,

While core.async is certainly nice (check out some of swannodette's cool ClojureScript demos too), I do find promises (and family) to be useful programming conveniences when concurrency is not the primary technical muscle being brought to solving the problem at hand. Towards this, I've been working on a Promise class for Amber and would like some feedback from the amber community on it.

The package's source is in the "promise" branch of my amber fork. <a href="https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsrikumarks%2Famber%2Fblob%2Fpromise%2Forg_sriku%2F_source%2FPromise.st\46sa\75D\46sntz\0751\46usg\75AFQjCNFvMbRKveTZhQSIXC9lZL0AiMTLdw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsrikumarks%2Famber%2Fblob%2Fpromise%2Forg_sriku%2F_source%2FPromise.st\46sa\75D\46sntz\0751\46usg\75AFQjCNFvMbRKveTZhQSIXC9lZL0AiMTLdw';return true;">https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st

It is work-in-progress, but is documented enough to be useful I think (click the "Doc" checkbox in Helios). Promise is based on the Promises/A+ specification, but is more smalltalk-ish and has some smalltalk-specific goodies - ex: you can send a message to the value being promised as though it were available right away .. and the result will be a promise that will yield the return value of the message when it eventually gets sent. In other words, you can use a promise for a value pretty much as though the value were available right away.

Best,
-Kumar

On Saturday, November 23, 2013 6:51:14 PM UTC+5:30, Andy Burnett wrote:

I was just watching Rich Hickey's core async presentation (<a href="http://www.infoq.com/presentations/clojure-core-async" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.infoq.com%2Fpresentations%2Fclojure-core-async\46sa\75D\46sntz\0751\46usg\75AFQjCNH_njJ3EfNx4qfoxDZcbh1A_0DHyg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.infoq.com%2Fpresentations%2Fclojure-core-async\46sa\75D\46sntz\0751\46usg\75AFQjCNH_njJ3EfNx4qfoxDZcbh1A_0DHyg';return true;">http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber.

Does amber/pharo have a queue system we can use?

Cheers
Andy

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">amber-lang+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "amber-lang" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe';return true;">https://groups.google.com/d/topic/amber-lang/cjY2Vym4UUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">amber-lang+...@googlegroups.com.

For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3DTfRPosMtAJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">amber-lang+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">https://groups.google.com/groups/opt_out.