SRFIs to consider adding

[WillClinger]

Here are some SRFIs we might consider adding:

SRFI 106  basic socket interface
SRFI 136  extensible record types
SRFI 137  minimal unique types
SRFI 138  compiling Scheme programs to executables
SRFI 139  syntax parameters
SRFI 142  bitwise operations (superseded by SRFI 151)
SRFI 147  custom macro transformers
SRFI 149  basic syntax-rules extensions
SRFI 150  hygienic ERR5RS record syntax (reduced)
SRFI 152  string library (reduced)

Some of those, such as SRFI 150, should be very easy. Others, such as SRFI 106, would be more difficult but are important enough to justify some effort. For many, a lot depends on whether there's a sample implementation that could be dropped into Larceny without too much effort.

Here are some that would be hard or undesirable for us to add:

SRFI 105  curly-infix expressions
                "should implement curly-infix-expressions in their datum readers by default"
SRFI 107  XML reader syntax
                too much grammar to add to the standard read syntax
SRFI 108  named quasi-literal constructors
                barely compatible with R7RS lexical syntax, related to SRFI 107
SRFI 109  extended string quasi-literals
                still more barely compatible syntax, related to SRFI 107 and 108
SRFI 110  sweet-expressions (t-expressions)
                a cleaner extension than SRFIs 107 through 109, but still
SRFI 140  immutable strings
                requires "abc" to read as an istring,
                distinguishable at run time from mutable strings

[WillClinger]

SRFI 148 and SRFI 150 are not yet final. The sample implementation of SRFI 150 depends on SRFI 148, whose specification is to be rewritten. It would therefore be premature to support either of those SRFIs.

Both of those SRFIs depend upon SRFI 147, which says

A Scheme system properly supporting this SRFI should ensure that the bindings of define-syntax, let-syntax, letrec-syntax, and syntax-rules exported from (scheme base) and (srfi 147) are respectively the same. Such a Scheme system should provide the feature identifier custom-macro-transformers. This cannot be achieved by a fully portable implementation using only the R7RS without redefining (scheme base).

That is not going to happen in Larceny, so Larceny will never support SRFI 147 "properly". Consequently Larceny will probably deprecate SRFIs 148 and 150 as well as SRFI 147.

[WillClinger]

SRFI 149 just went final a few days ago. I thought it was describing a semantics Larceny had already implemented, but it wasn't.

The discrepancy may be a mistake in the SRFI 149 document, resulting from an apparent bug in the sample implementation taken from Chibi, which matches apparent bugs in Kawa and Sagittarius. If that is so, and an erratum is issued, then supporting SRFI 149 in Larceny will be trivial. On the other hand, if SRFI 149 really intended to break examples such as Al Petrofsky's foo2 example (in the SRFI 149 discussion archive), then Larceny will not support SRFI 149.

[mnieper]

I have a question about SRFI 147: You say on https://github.com/larcenists/larceny/wiki/DeprecatedSRFIs that the four keywords it defines, namely define-syntax, let-syntax, letrec-syntax, and syntax-rules, are fundamentally incompatible with SRFI 9, SRFI 99, SRFI 131, and R6RS. Can you elaborate a bit, please?

The extensions proposed in SRFI 147 should be backward compatible.

[WillClinger]

My mistake. I had gotten the impression that all of these macro SRFIs were related to an attempt to change the semantics of records so field names would no longer be symbols, which is SRFI 150.

Larceny will not support SRFI 149, because our discussion has established that SRFI 149 is incompatible with the R6RS semantics, which Larceny has retained in its implementation of R7RS (small).

I will take another look at SRFI 148.

[mnieper]

I had gotten the impression that all of these macro SRFIs were related to an attempt to change the semantics of records so field names would no longer be symbols, which is SRFI 150.

Although the sample implementation of SRFI 150 uses SRFI 148, and thus SRFI 147 (mainly for demonstration purposes for SRFI 148 and to get easily understandable code), it is by no means necessary.

SRFI 150 can be easily implemented by hand, as much as the macros of SRFI 131 and SRFI 136 are implemented. (Maybe I should add such an implementation to the repository of SRFI 150.)

For Larceny's philosophy, the problem remains, though, namely that SRFI 150 is compatible with the R7RS, but not with SRFI 99, to which the R7RS is incompatible.

[WillClinger]

Larceny's implementation of define-record-type is fully compatible with the R7RS, R6RS, SRFI 9, SRFI 99, and SRFI 131 record systems. That proves SRFI 99 is compatible with the R7RS.

I am aware that some people are choosing to interpret the R7RS specification otherwise, and a few of those people are attempting to buttress their interpretation by rewriting the history of the SRFI 9, SRFI 99, SRFI 131, and R6RS record systems. Not all of us are fooled by their efforts. Those of us who contributed to the design of those record systems and implemented them are especially unlikely to be fooled.