I've found that scsh's 0.7's temp-file-iterate is broken in myriad ways, and the first example using it is further broken by create-hard-link not raising an error if the newname is in a different file system, in which case it silently makes a copy there.
I count that as a (well-intentioned) bug in create-hard-link; copying is by no means linking.
While I don't like how temp-file-iterate's contract allows it to fail after trying some number of iterations,
As long as it doesn't fail silently, I think that's a reasonable allowance.
it does provide unique and currently undocumented functionality because it requires an "~a" as supplied in scsh's *temp-file-template* fluid variable. This is handed to format, allowing almost precise filenames.
I think it's enough to just allow a fixed prefix rather than the full generality of format (I don't want to introduce a dependency). If you think both a fixed prefix and a fixed suffix is required, then we could just treat `~a` specially, I suppose.
I now think that when a SRFI 170 identifier is bound to something incompatible that a new name should be used. In particular `temporary-file-iterate` would work fine here, and the `exec` functions can be changed to `execute` functions, since they have to be implemented in scsh as a dispatch to the correct `exec` and `%exec` functions. I think there are no other bad cases. With this change we can make a SRFI 170 code file that works exactly as specified on top of scsh, which will certainly make Art happier (and perhaps remove all the detail in the Implementation section, but perhaps not).
So my requested decisions are "fix or document", as well as should I add headers to the Implementation section. Since none of the section 3.10 Time features are implemented, nor can they be as documented to work with scsh 0.7, which take rationals, I think we should be adding a sample code section to the srfi GitHub repository.
Headers in the Implementation section, or any other such editorial change, is just fine.
While I'm at it, I should mention that I took the liberty of renaming perms and mode to permission-bits after discovering that wonderful and explanatory usage elsewhere in the SRFI, that significantly decreases the need to document those argument. This does preclude a read and then write version of set-file-mode like chmod(1), which really shouldn't be done at this level, but symbolic strings to bit mask conversion can and should be done with a helper procedure.
LGTM.
No saves, Antonio, loke es morirse en su lingua. Es komo kedarse soliko en el
silensyo kada dya ke Dyo da, komoser sikileoso sin saver porke.
--Marcel Cohen, 1985