Re: [racket-users] Structured Concurrency in Racket

[Paulo Matos]

On 07/10/2019 21:01, Arie Schlesinger wrote:
> Can somebody specify how to use racket in jupyter notebook ?
> Thanks
> 

There have been earlier threads about that you might want to look at.
https://groups.google.com/d/msg/racket-users/qw7u9pNFbuQ/eot1Acw7DAAJ

I don't know the answer to your question but you might have better luck
at an answer if you post it as a separate email instead of a sub-message
to an unrelated thread.

Good luck,
Paulo

> On Mon, Oct 7, 2019 at 21:59 jab  > wrote:
> 
> Yeah, I’d say give a closer read to
> 
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> 
> Excerpting a footnote:
> 
> > For those who can't possibly pay attention to the text without
> first knowing whether I'm aware of their favorite paper, my current
> list of topics to include in my review are: the "parallel
> composition" operator in Cooperating/Communicating Sequential
> Processes and Occam, the fork/join model, Erlang supervisors, Martin
> Sústrik's article on Structured concurrency and work on libdill, and
> crossbeam::scope / rayon::scope in Rust. [Edit: I've also been
> pointed to the highly relevant golang.org/x/sync/errgroup
>  and github.com/oklog/run
>  in Golang.]
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to racket-users+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/racket-users/02b4c456-2af1-4306-b749-b7d54173c7dc%40googlegroups.com.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAMJd8C5JqCU82gg3ZoRPwV4H1_SxGQTSht9UXCWFtneSp_MVOA%40mail.gmail.com
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0e8e6913-fe30-3a45-2c17-eac6e1812b38%40linki.tools.

Re: [racket-users] Structured Concurrency in Racket

[Luke Whittlesey]

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 delimited continuations and processes are managed
in a tree. If a parent process exits the children are canceled and
finalized.

On Mon, Oct 7, 2019 at 4:08 PM George Neuner  wrote:
>
>
> On 10/7/2019 1:46 PM, jab wrote:
> > Coming across 
> > https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/
> >  just provoked me to search for discussion of structured concurrency in 
> > Racket. I didn’t immediately find much.* I hope that doesn’t mean that the 
> > interesting work that’s being discussed over in 
> > https://trio.discourse.group/c/structured-concurrency etc. has been largely 
> > unknown by the Racket community. Trio is having a profound impact on the 
> > future of concurrency, not just in Python but in many other languages. 
> > There’s even a post on Wikipedia now: 
> > https://en.wikipedia.org/wiki/Structured_concurrency
> >
> > (For anyone new to the term, 
> > https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> >  might be the best starting point. One persuasive example shows Nathaniel 
> > live coding a correct implementation of RFC 655 “Happy Eyeballs” in 40 
> > lines of Python: 
> > https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals
> >   (For comparison, Twisted’s implementation took hundreds of lines and 
> > still had a logic bug after years of work.) There is also some related 
> > reading in https://github.com/python-trio/trio/wiki/Reading-list.)
> >
> > I hope this post provokes discussion of structured concurrency in Racket. 
> > It’d be fascinating to read more of your thoughts!
> >
> > Thanks,
> > Josh
> >
> > * For example, Googling “structured concurrency racket” turned up mostly 
> > just a brief mention of Racket’s custodians in the bottom-most comment on 
> > this post: http://250bpm.com/blog:71
>
> "Structured concurrency" as defined by those articles really applies
> only to programs that operate in distinct phases -  which is a pretty
> good description of many science programs  - but such programs represent
> a (important, but) small subset of all parallel programs.
>
> Racket's APIs are designed to support general parallelism, not just
> phased parallelism.
>
> I suppose an argument could be made for syntax explicitly aimed at
> phased parallelism ... but using macros, such syntax could be built on
> top of the existing parallel (future, thread, place) APIs - so there is
> nothing stopping you, or anyone else, from creating a "structured
> concurrency" package that everyone can use.
>
>
> One problem I foresee is defining a reasonable syntax and semantics.
> Most of the languages that promote "structured" concurrency have C-like
> syntax.  Moreover they vary considerably in semantics - in some of them
> the spawning thread stops immediately and can't continue until its
> children exit, but other allow the spawning thread to continue until it
> executes an explicit join / wait for its children.
>
> The Lisp/Scheme based idioms of S-expr Racket are very different from
> those of C-like languages, and whether or not some "Racket2"
> materializes having a more C-like syntax, many people like Racket just
> the way it is.  I can envision heated debates about what should be the
> proper "structuring" semantics and what syntax best represents them.
>
> YMMV,
> George
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/8b83ff75-7b57-f3f1-0514-46170c9c3141%40comcast.net.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CA%2Bce6i39GYb8fVnb%2B91iGEdyTCnegaZLx%3DSHfuZ5zY1wqn%3D2-w%40mail.gmail.com.

Re: [racket-users] Structured Concurrency in Racket

[George Neuner]

On 10/7/2019 1:46 PM, jab wrote:

Coming across 
https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/
 just provoked me to search for discussion of structured concurrency in Racket. 
I didn’t immediately find much.* I hope that doesn’t mean that the interesting 
work that’s being discussed over in 
https://trio.discourse.group/c/structured-concurrency etc. has been largely 
unknown by the Racket community. Trio is having a profound impact on the future 
of concurrency, not just in Python but in many other languages. There’s even a 
post on Wikipedia now: https://en.wikipedia.org/wiki/Structured_concurrency

(For anyone new to the term, 
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
 might be the best starting point. One persuasive example shows Nathaniel live 
coding a correct implementation of RFC 655 “Happy Eyeballs” in 40 lines of 
Python: 
https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals
  (For comparison, Twisted’s implementation took hundreds of lines and still 
had a logic bug after years of work.) There is also some related reading in 
https://github.com/python-trio/trio/wiki/Reading-list.)

I hope this post provokes discussion of structured concurrency in Racket. It’d 
be fascinating to read more of your thoughts!

Thanks,
Josh

* For example, Googling “structured concurrency racket” turned up mostly just a 
brief mention of Racket’s custodians in the bottom-most comment on this post: 
http://250bpm.com/blog:71


"Structured concurrency" as defined by those articles really applies 
only to programs that operate in distinct phases -  which is a pretty 
good description of many science programs  - but such programs represent 
a (important, but) small subset of all parallel programs.


Racket's APIs are designed to support general parallelism, not just 
phased parallelism.


I suppose an argument could be made for syntax explicitly aimed at 
phased parallelism ... but using macros, such syntax could be built on 
top of the existing parallel (future, thread, place) APIs - so there is 
nothing stopping you, or anyone else, from creating a "structured 
concurrency" package that everyone can use.



One problem I foresee is defining a reasonable syntax and semantics.   
Most of the languages that promote "structured" concurrency have C-like 
syntax.  Moreover they vary considerably in semantics - in some of them 
the spawning thread stops immediately and can't continue until its 
children exit, but other allow the spawning thread to continue until it 
executes an explicit join / wait for its children.


The Lisp/Scheme based idioms of S-expr Racket are very different from 
those of C-like languages, and whether or not some "Racket2" 
materializes having a more C-like syntax, many people like Racket just 
the way it is.  I can envision heated debates about what should be the 
proper "structuring" semantics and what syntax best represents them.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8b83ff75-7b57-f3f1-0514-46170c9c3141%40comcast.net.

Re: [racket-users] Structured Concurrency in Racket

[Arie Schlesinger]

Can somebody specify how to use racket in jupyter notebook ?
Thanks

On Mon, Oct 7, 2019 at 21:59 jab  wrote:

> Yeah, I’d say give a closer read to
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
>
> Excerpting a footnote:
>
> > For those who can't possibly pay attention to the text without first
> knowing whether I'm aware of their favorite paper, my current list of
> topics to include in my review are: the "parallel composition" operator in
> Cooperating/Communicating Sequential Processes and Occam, the fork/join
> model, Erlang supervisors, Martin Sústrik's article on Structured
> concurrency and work on libdill, and crossbeam::scope / rayon::scope in
> Rust. [Edit: I've also been pointed to the highly relevant
> golang.org/x/sync/errgroup and github.com/oklog/run in Golang.]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/02b4c456-2af1-4306-b749-b7d54173c7dc%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAMJd8C5JqCU82gg3ZoRPwV4H1_SxGQTSht9UXCWFtneSp_MVOA%40mail.gmail.com.

Re: [racket-users] Structured Concurrency in Racket

[jab]

Yeah, I’d say give a closer read to 
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

Excerpting a footnote:

> For those who can't possibly pay attention to the text without first knowing 
> whether I'm aware of their favorite paper, my current list of topics to 
> include in my review are: the "parallel composition" operator in 
> Cooperating/Communicating Sequential Processes and Occam, the fork/join 
> model, Erlang supervisors, Martin Sústrik's article on Structured concurrency 
> and work on libdill, and crossbeam::scope / rayon::scope in Rust. [Edit: I've 
> also been pointed to the highly relevant golang.org/x/sync/errgroup and 
> github.com/oklog/run in Golang.]

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/02b4c456-2af1-4306-b749-b7d54173c7dc%40googlegroups.com.

Re: [racket-users] Structured Concurrency in Racket

[Matt Jadud]

Hi Josh,

Racket has a number of powerful concurrency libraries/extensions that
handle both concurrent execution of code in a single process as well as
parallel execution across multiple processes/hosts. There is the "futures"
library, which might be the most similar to Trio.

https://docs.racket-lang.org/reference/futures.html

However, there are libraries that provide a larger lift, and are
grounded in language traditions that tie back to algebras for reasoning
about parallel systems. The channel library, and the code that builds on it
("places"), are examples.

https://docs.racket-lang.org/reference/channel.html

https://docs.racket-lang.org/guide/parallelism.html

The history of formal reasoning, and implementation of, mechanisms for
concurrency and parallelism go back to at least the... 70's?

https://en.wikipedia.org/wiki/Communicating_sequential_processes

"Structured concurrency" does not, from the link(s) provided, seem to be
anything that stands out from this long tradition. (Or, if you prefer,
computer scientists have been reasoning about, building systems around, and
integrating into languages notions of parallelism and concurrency for
roughly 40+ years.)

So, personally, I would say that Racket has multiple libraries (which,
because of the nature of Racket, are in some cases extensions to the base
language) that implement structured concurrency.

Unless I'm completely misunderstanding your post.

Cheers,
Matt


On Mon, Oct 7, 2019 at 1:46 PM jab  wrote:

> Coming across
> https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/
> just provoked me to search for discussion of structured concurrency in
> Racket. I didn’t immediately find much.* I hope that doesn’t mean that the
> interesting work that’s being discussed over in
> https://trio.discourse.group/c/structured-concurrency etc. has been
> largely unknown by the Racket community. Trio is having a profound impact
> on the future of concurrency, not just in Python but in many other
> languages. There’s even a post on Wikipedia now:
> https://en.wikipedia.org/wiki/Structured_concurrency
>
> (For anyone new to the term,
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> might be the best starting point. One persuasive example shows Nathaniel
> live coding a correct implementation of RFC 655 “Happy Eyeballs” in 40
> lines of Python:
> https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals
> (For comparison, Twisted’s implementation took hundreds of lines and still
> had a logic bug after years of work.) There is also some related reading in
> https://github.com/python-trio/trio/wiki/Reading-list.)
>
> I hope this post provokes discussion of structured concurrency in Racket.
> It’d be fascinating to read more of your thoughts!
>
> Thanks,
> Josh
>
> * For example, Googling “structured concurrency racket” turned up mostly
> just a brief mention of Racket’s custodians in the bottom-most comment on
> this post: http://250bpm.com/blog:71
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/bb36e50a-a77b-4c5b-b144-71ce647069b7%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAAGM455HSfVgBcu%2B1FZc-mubYaeYEFZb1XxZo_z_sQNqRDO4XQ%40mail.gmail.com.

[racket-users] Structured Concurrency in Racket

[jab]

Coming across 
https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/
 just provoked me to search for discussion of structured concurrency in Racket. 
I didn’t immediately find much.* I hope that doesn’t mean that the interesting 
work that’s being discussed over in 
https://trio.discourse.group/c/structured-concurrency etc. has been largely 
unknown by the Racket community. Trio is having a profound impact on the future 
of concurrency, not just in Python but in many other languages. There’s even a 
post on Wikipedia now: https://en.wikipedia.org/wiki/Structured_concurrency

(For anyone new to the term, 
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
 might be the best starting point. One persuasive example shows Nathaniel live 
coding a correct implementation of RFC 655 “Happy Eyeballs” in 40 lines of 
Python: 
https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals
  (For comparison, Twisted’s implementation took hundreds of lines and still 
had a logic bug after years of work.) There is also some related reading in 
https://github.com/python-trio/trio/wiki/Reading-list.)

I hope this post provokes discussion of structured concurrency in Racket. It’d 
be fascinating to read more of your thoughts!

Thanks,
Josh

* For example, Googling “structured concurrency racket” turned up mostly just a 
brief mention of Racket’s custodians in the bottom-most comment on this post: 
http://250bpm.com/blog:71

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/bb36e50a-a77b-4c5b-b144-71ce647069b7%40googlegroups.com.