Partitioning the problem space
Lassi Kortela
(09 May 2019 13:05 UTC)
|
Re: Partitioning the problem space
John Cowan
(09 May 2019 23:26 UTC)
|
Re: Partitioning the problem space
Arthur A. Gleckler
(09 May 2019 23:33 UTC)
|
Re: Partitioning the problem space
Lassi Kortela
(10 May 2019 11:12 UTC)
|
Re: Partitioning the problem space
Lassi Kortela
(10 May 2019 13:49 UTC)
|
Re: Partitioning the problem space
John Cowan
(11 May 2019 00:30 UTC)
|
Re: Partitioning the problem space Lassi Kortela (14 May 2019 17:06 UTC)
|
Re: Partitioning the problem space
John Cowan
(15 May 2019 10:34 UTC)
|
Re: Partitioning the problem space Lassi Kortela 14 May 2019 17:06 UTC
> The partitioning could start by thinking about (import (srfi ...)) > expressions -- a natural unit of code of that makes sense for someone to > import would mean good SRFI boundaries. Another test is whether it makes > sense to for a Scheme to implement functionality A without functionality > B. If it does then A and B could go into their own SRFIs. > > Some immediate observations: > > * For things that only work on Windows, it's natural to (import (srfi w)). > * For things that only work on Unix, natural to (import srfi u)). > * For things that work on both, (import (srfi b)) is clear. > * It makes sense to support a file system without also supporting > networking. > * It makes sense to support subprocesses without supporting terminals. > * It doesn't make as much sense to support subprocesses without > supporting signals, because signals come up when waiting for > subprocesses (they can be terminated by signal, or stopped and > continued, or the parent process can signal them to terminate, etc.) > * etc. Any thoughts on this? If people are sympathetic could try to draft a fairly precise partitioning of SRFIs to have some details based on which to continue discussion. The 60-day deadline for SRFI 170 is at the beginning of July so we'd best set the general course soon.