John Cowan <xxxxxx@ccil.org> writes:

> On Thu, Mar 5, 2020 at 8:08 AM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>
>> FuturesCowan also drops mutexes and condition variables. How will the
>> threads coordinate their actions without this?
>
> It hides them so that threads can be standardized even though thread
> coordination is still under consideration. Specifically, I am going to
> propose go-channels as the standard coordination interface, using
> conditions and mutexes under the table. I don't yet have a proposal,
> but I want to be able to standardize threads first.

In Golang, operations on channels are most commonly hidden behind syntax
such as <- and select. But since this is Scheme, I think that the
coordination operations should be first class. This would be good
because this allows them to be composed, be stored in data structures,
etc., which is something we all enjoy today with closures and
continuations.

Might I suggest finding inspiration in Concurrent ML instead of Golang.

Here are some instances of Scheme and Concurrent ML together:

"a new concurrent ml"
<https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml>

CML for GNU Guile <https://github.com/wingo/fibers/wiki/Manual>

CML in Loko Scheme <https://scheme.fail/manual/loko.html#Fibers>

CML in Scheme 48
<https://www.s48.org/1.9.2/manual/manual-Z-H-8.html#node_sec_7.8>

CML in Scheme <http://mumble.net/~campbell/darcs/scheme-cml/>

Regards,

--
Göran Weinholt   | https://weinholt.se/
Debian developer | 73 de SA6CJK