[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Shaun LeBron
agreed that core.async is not relevant to this discussion.

I suppose the main question is—how should ES6+ (ES Next) features be made 
available to CLJS users.  Is the story going to be  "All of ES5 is 
accessible from CLJS—but you must use an external JS file for ES Next 
features"?

(I added your transpile link to macros section. Also, I'd love to see 
emitting ES Modules in the future, though I'm not sure of implications 
there)

On Friday, May 25, 2018 at 11:22:26 AM UTC-5, Thomas Heller wrote:
>
> Yes, core.async is not great for this but it was also not meant for this. 
> The big abstraction there are channels or CSP. There are "zero" channels 
> involved in your example so you could probably find a better abstraction to 
> fit here.
>
> There are several different concurrency models and all of them have 
> drawbacks. As I said before I'm for adding support for async/await and 
> generators but core.async should not even be part of the argument IMHO. I'm 
> not trying to convince anyone that core.async is the best solution ever. I 
> remember vividly how desperately I wanted a proper Actor-like concurrency 
> primitive when I came over from Erlang. I actually only understood the 
> drawbacks of Actors after I learned about CSP.
>
> I made this example a while ago showing what Closure does when rewriting 
> async/await to ES3.
> https://gist.github.com/thheller/82ca9ef8a04b58aafa4624edbac383ac
>
> We could emit that JS code directly using a few macros. The only reason 
> emitting the ES6+ code makes sense is due to tool support and maybe having 
> slightly more compact code, which is probably not a factor after :advanced 
> is done with it. We can already interop with all of it very easily, just 
> writing equivalent code is not ideal.
>
> To be honest just adding support for async/await and generators alone 
> doesn't make much sense to me. At that point we should probably look into 
> emitting ES6+ESM directly instead and make proper use of all the features 
> that has. Given that Closure support for ES6 is getting much better that 
> might make sense at some point.
>
>
> On Friday, May 25, 2018 at 4:45:22 PM UTC+2, Shaun LeBron wrote:
>>
>> Right!  The proposal mentions that go-blocks must check for a closed 
>> channel at every step in order to exit early. So I'll revise the 
>> title—core.async cannot stop *arbitrary* go-blocks.
>>
>> For example, with this staggered animation code, it's not immediately 
>> clear to me how to exit after any step. In JS, it pulls the plug for free.
>>
>> (go
>>   (dotimes [_ 3]
>> (swap! game assoc :board cleared)
>> (> (swap! game assoc :board board)
>> (>   (swap! game assoc :board cleared)
>>   (>   (swap! game assoc :board collapsed))
>>
>>
>> Anyone coming from the Unity game engine will recognize this feature as 
>> the StopCoroutine function. Core.async does not have such a feature.  the 
>> ergonomics matter!
>>
>> On Friday, May 25, 2018 at 3:28:49 AM UTC-5, Thomas Heller wrote:
>>>
>>>
 not quite! core.async doesn't allow you to cancel a go-block (to my 
 knowledge), which JS allows.  I added a section on this:


 https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#coreasync


>>> This is incorrect. Closing a channel can be used to "end" a loop. In 
>>> addition it is possible to use alt! or alts! with an additional "control" 
>>> channel (or more) and "selecting" which channel to work on.
>>>
>>>
>>>
>>> (defn foo []
>>>   (let [ch (async/chan)]
>>> (go (loop [i 100]
>>>   (when (pos? i)
>>> (>> (when (>! ch i)
>>>   (recur (dec i)
>>> (prn :loop-terminated))
>>> ch))
>>>
>>> (go (let [ch (foo)]
>>>   (prn (>>   (prn (>>   (async/close! ch)
>>>   (prn (>>
>>>
>>>  
>>> In addition the "loop" is dependent on the "ch" reference. If that gets 
>>> garbage collected the loop will be as well, similar to generators or 
>>> async/await.
>>>
>>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Shaun LeBron
thanks!  
added: 
https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#macros

On Friday, May 25, 2018 at 1:24:07 PM UTC-5, Didier wrote:
>
> For example this blog post shows compatibility: 
> https://blog.jeaye.com/2017/09/30/clojurescript-promesa/
>
> And also gives a nice little macro so you can use similar syntax to async 
> and await.
>
> The biggest downside is that all the sugar is in a macro, and thus can't 
> rewrite across function boundaries. Though I think that's also true in JS.
>
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Didier
For example this blog post shows compatibility: 
https://blog.jeaye.com/2017/09/30/clojurescript-promesa/

And also gives a nice little macro so you can use similar syntax to async and 
await.

The biggest downside is that all the sugar is in a macro, and thus can't 
rewrite across function boundaries. Though I think that's also true in JS.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Thomas Heller
Yes, core.async is not great for this but it was also not meant for this. 
The big abstraction there are channels or CSP. There are "zero" channels 
involved in your example so you could probably find a better abstraction to 
fit here.

There are several different concurrency models and all of them have 
drawbacks. As I said before I'm for adding support for async/await and 
generators but core.async should not even be part of the argument IMHO. I'm 
not trying to convince anyone that core.async is the best solution ever. I 
remember vividly how desperately I wanted a proper Actor-like concurrency 
primitive when I came over from Erlang. I actually only understood the 
drawbacks of Actors after I learned about CSP.

I made this example a while ago showing what Closure does when rewriting 
async/await to ES3.
https://gist.github.com/thheller/82ca9ef8a04b58aafa4624edbac383ac

We could emit that JS code directly using a few macros. The only reason 
emitting the ES6+ code makes sense is due to tool support and maybe having 
slightly more compact code, which is probably not a factor after :advanced 
is done with it. We can already interop with all of it very easily, just 
writing equivalent code is not ideal.

To be honest just adding support for async/await and generators alone 
doesn't make much sense to me. At that point we should probably look into 
emitting ES6+ESM directly instead and make proper use of all the features 
that has. Given that Closure support for ES6 is getting much better that 
might make sense at some point.


On Friday, May 25, 2018 at 4:45:22 PM UTC+2, Shaun LeBron wrote:
>
> Right!  The proposal mentions that go-blocks must check for a closed 
> channel at every step in order to exit early. So I'll revise the 
> title—core.async cannot stop *arbitrary* go-blocks.
>
> For example, with this staggered animation code, it's not immediately 
> clear to me how to exit after any step. In JS, it pulls the plug for free.
>
> (go
>   (dotimes [_ 3]
> (swap! game assoc :board cleared)
> ( (swap! game assoc :board board)
> (   (swap! game assoc :board cleared)
>   (   (swap! game assoc :board collapsed))
>
>
> Anyone coming from the Unity game engine will recognize this feature as 
> the StopCoroutine function. Core.async does not have such a feature.  the 
> ergonomics matter!
>
> On Friday, May 25, 2018 at 3:28:49 AM UTC-5, Thomas Heller wrote:
>>
>>
>>> not quite! core.async doesn't allow you to cancel a go-block (to my 
>>> knowledge), which JS allows.  I added a section on this:
>>>
>>>
>>> https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#coreasync
>>>
>>>
>> This is incorrect. Closing a channel can be used to "end" a loop. In 
>> addition it is possible to use alt! or alts! with an additional "control" 
>> channel (or more) and "selecting" which channel to work on.
>>
>>
>>
>> (defn foo []
>>   (let [ch (async/chan)]
>> (go (loop [i 100]
>>   (when (pos? i)
>> (> (when (>! ch i)
>>   (recur (dec i)
>> (prn :loop-terminated))
>> ch))
>>
>> (go (let [ch (foo)]
>>   (prn (>   (prn (>   (async/close! ch)
>>   (prn (>
>>
>>  
>> In addition the "loop" is dependent on the "ch" reference. If that gets 
>> garbage collected the loop will be as well, similar to generators or 
>> async/await.
>>
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Shaun LeBron
Right!  The proposal mentions that go-blocks must check for a closed 
channel at every step in order to exit early. So I'll revise the 
title—core.async cannot stop *arbitrary* go-blocks.

For example, with this staggered animation code, it's not immediately clear 
to me how to exit after any step. In JS, it pulls the plug for free.

(go
  (dotimes [_ 3]
(swap! game assoc :board cleared)
(
>
>> not quite! core.async doesn't allow you to cancel a go-block (to my 
>> knowledge), which JS allows.  I added a section on this:
>>
>>
>> https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#coreasync
>>
>>
> This is incorrect. Closing a channel can be used to "end" a loop. In 
> addition it is possible to use alt! or alts! with an additional "control" 
> channel (or more) and "selecting" which channel to work on.
>
>
>
> (defn foo []
>   (let [ch (async/chan)]
> (go (loop [i 100]
>   (when (pos? i)
> ( (when (>! ch i)
>   (recur (dec i)
> (prn :loop-terminated))
> ch))
>
> (go (let [ch (foo)]
>   (prn (   (prn (   (async/close! ch)
>   (prn (
>
>  
> In addition the "loop" is dependent on the "ch" reference. If that gets 
> garbage collected the loop will be as well, similar to generators or 
> async/await.
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Didier
I think compatibility shouldn't be an issue. Doesn't the async fn just return a 
promise? So you should be able to call an async fn from ClojureScript. 

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.


[ClojureScript] Re: When will the async/await feature in ES8 be introduced in ClojureScript?

2018-05-25 Thread Thomas Heller

>
>
> not quite! core.async doesn't allow you to cancel a go-block (to my 
> knowledge), which JS allows.  I added a section on this:
>
>
> https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#coreasync
>
>
This is incorrect. Closing a channel can be used to "end" a loop. In 
addition it is possible to use alt! or alts! with an additional "control" 
channel (or more) and "selecting" which channel to work on.



(defn foo []
  (let [ch (async/chan)]
(go (loop [i 100]
  (when (pos? i)
(! ch i)
  (recur (dec i)
(prn :loop-terminated))
ch))

(go (let [ch (foo)]
  (prn (https://groups.google.com/group/clojurescript.