I decided for the latter, cleanly separating the R7RS semantics from the semantics of this SRFI, and so the proposed library name is (scheme promise) with no name clash with an existing library of the R7RS.


Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> schrieb am So., 16. Juli 2017 um 15:28 Uhr:

In its current incarnation, this SRFI states:

"An R7RS implementation that implements promises as described here as part of its (scheme lazy) library provides the feature identifier functional-identifiers. In that case, the bindings exported by (srfi 155) are the same as the respective bindings exported by (scheme lazy).

Technically, such an R7RS implementation does not completely conform to the small language as described by the R7RS. Nevertheless, such an implementation shall still provide the r7rs feature identifier."

I would like to know from people more familiar with standardization issues than me and from implementers whether this requirement of SRFI 155 is a viable one. An implementation exposing the interface of this SRFI in the ‘(scheme lazy)’ namespace will never be an honest implementation of the R7RS as written because of the semantic change of ‘force‘ with respect to dynamic extents. (The idea behind this requirement of SRFI 155 is that no sensible or existing program would break with the new semantics.)

Should this SRFI be adopted in a forthcoming standard of the Scheme programming language, this language would therefore never be completely backward-compatible with the R7RS (this may or may not be a good idea, depending on whether the community comes to the conclusion that some corners of the R7RS should be fixed in the next iteration of the language or not).

Alternatively, the above quotation from this SRFI could changed into:

"It is recommended that the interface described in this SRFI will be made available under the namespace ‘(scheme promise)’ in future revisions of the Scheme programming language that build upon the R7RS. When this happens, ‘(scheme lazy)’ should become deprecated and remain solely for backward compatibility with the R7RS."