Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-12 Thread Nathaniel Smith
:wave: Hi all, Josh pointed me to this thread. I'm the author of that blog post he linked to. Sam Tobin-Hochstadt wrote: > The Racket community, and even more so the design of Racket > concurrency APIs, is very strongly influenced by the academic side of > Racket. As far as I can tell,

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-10 Thread Philip McGrath
On Thu, Oct 10, 2019 at 2:42 AM Zelphir Kaltstahl < zelphirkaltst...@gmail.com> wrote: > … If that works for arbitrary serializable-lambda with only serializable > parts, I could continue my process pool project. > Yes, this would work for any value created by `serial-lambda`. > The only issue

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-10 Thread Zelphir Kaltstahl
Hi! Hmmm, that code example looks simple enough. If that works for arbitrary serializable-lambda with only serializable parts, I could continue my process pool project. The only issue would then be, that any user of it would have to know in advance, that they cannot define their lambdas as usual,

[racket-users] Re: Structured Concurrency in Racket

2019-10-10 Thread George Neuner
On Wed, 9 Oct 2019 16:15:14 -0400, Sam Tobin-Hochstadt wrote: >The Racket community, and even more so the design of Racket >concurrency APIs, is very strongly influenced by the academic side of >Racket. As far as I can tell, structured concurrency is fairly close >to what is traditionally called

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread Philip McGrath
On Wed, Oct 9, 2019 at 2:09 PM Zelphir Kaltstahl wrote: > I was wrongly under the impression, that serializable-lambda are supposed > to work out of the box, when sending them over channels, without needing to > do any further work ("are serialized automatically" instead of "can be >

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread Sam Tobin-Hochstadt
The Racket community, and even more so the design of Racket concurrency APIs, is very strongly influenced by the academic side of Racket. As far as I can tell, structured concurrency is fairly close to what is traditionally called the fork/join model. Concurrency in Racket is usually structured in

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread jab
For example, here’s a more functional implementation of Happy Eyeballs in Clojure, using the author’s “missionary” library (a functional effect and streaming system): https://cljdoc.org/d/missionary/missionary/b.11/doc/readme/guides/happy-eyeballs -- You received this message because you are

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread Zelphir Kaltstahl
Hi George! I was wrongly under the impression, that serializable-lambda are supposed to work out of the box, when sending them over channels, without needing to do any further work ("are serialized automatically" instead of "can be serialized"). This is what I would have expected, as it seems to

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread Zelphir Kaltstahl
True. However, here comes the big "but": What about capturing the environment of expressions? For example I might have identifiers in my S-expressions bound to potentially a lot of data, which must also be send through the channel. It would be painful (if not impossibly at the time of writing the

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread jab
So far from this thread, it seems the idea of Structured Concurrency hasn’t yet made it into the Racket world. I’ll be interested to see if it gets adopted in Racket in the future (or at least better understood) as its adoption grows elsewhere. In the meantime, in case it helps illustrate the

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread George Neuner
On 10/9/2019 2:34 AM, Zelphir Kaltstahl wrote: I don't think places are a good example for good support of parallelism. Hoare's "Communicating Sequential Processes" is a seminal work in Computer Science.  We can argue about whether places are - or not - a good implementation of CSP,  but

Re: [racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread David Storrs
Note that it's possible to send S-expressions through a channel and then eval them on the far end. This would let you do something like this: (hash 'func 'my-predefined-lambda 'args '(arg1 arg2)) Which calls a predefined function, or: (hash 'install '(lambda (username) (displayln (~a "Hello, "

[racket-users] Re: Structured Concurrency in Racket

2019-10-09 Thread Zelphir Kaltstahl
I don't think places are a good example for good support of parallelism. It is difficult to get a flexible multi processing implementation done, without hard-coding the lambdas, that run in each place, because we cannot send serializable lambdas (which also are not core, but only exist in the web

[racket-users] Re: Structured Concurrency in Racket

2019-10-08 Thread George Neuner
On Tue, 8 Oct 2019 10:36:42 -0400, Luke Whittlesey wrote: >I think the ceu language has a nice model of what I would consider >"structured". http://ceu-lang.org/ It has automatic cancellation and >finalization. Racket can easily support this model. Await statements >are captured through