3.1, Errors, really would have to appear either as a separate and ridiculously short SRFI or would have to be put in all the SRFIs.
Beyond that, I think the following partition is reasonable:
(a) 3.2 I/O + 3.3 File system
(b) 3.4 Processes + 3.5 Process state + 3.9 Signal system
(c) 3.6 User and group databases + 3.8 System parameters
(d) 3.10 Time + 3.11 Environment variables + 3.12 Terminal device control
But do I think it''s *necessary*? No, not really. It's a big SRFI, but not so huge that I think it needs breaking up.
> 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.