Re: Preliminary proposal for a process library Lassi Kortela 19 Aug 2019 16:29 UTC

> I'm not much in favor of the Builder pattern, because it involves
> creating a mutable object and then setting it up with a series of
> mutator calls.  It's really a substitute for not having keyword
> arguments

I'm not quite sure which is a substitute for which :) Granted that
builder object operations compose vastly nicer when the objects are
immutable. Keyword args would be great but I haven't been able to
reconcile keyword objects and function-call-only keyword syntax as
pondered on srfi-discuss.

> See also more generally Peter Norvig's slides at
> <http://norvig.com/design-patterns/design-patterns.pdf> on why patterns
> are signs of the lack of fully capable abstraction in non-Lisp languages.

Largely agree. But there's no clear distinction between what's a design
pattern and what is not.

> Another of my opinions:  the One Big Event Loop is very much an
> anti-pattern.

Agreed (big state machines are impenetrable to mere mortals). But I
meant a poll procedure that can be used to poll any kind of object, not
only file descriptors or only processes. You still have to tell it which
objects (or which types of object/event) to wait for, but you can mix
many types. WaitForSingleObject() is something like that on Windows.

> On top of
> my proposed interface it would be easy to have a thread that waits for
> process termination and puts the process object into a go-channel, which
> the rest of the application can read as desired.

If I've understood correctly, Gambit's whole runtime is based around
unified polling like this (lots of different kinds of objects are
represented by a variety of ports). However, I can't find the central
poll procedures themselves in the manual or wiki.

Just noticed that each Gambit thread has its own mailbox (queue) so most
of the building blocks for go-like channels could be in place. IIRC Go
channels are higher-order (you can send a channel over another channel);
does any Scheme have something like this?

> go-channels trivially have their own select (a macro), it becomes
> straightforward to selectively reconstitute whatever sources of events
> you need to interleave without being troubled by the rest.

That sounds like the unified poller I meant.