-
Notifications
You must be signed in to change notification settings - Fork 32
DeprecatedSRFIs
Larceny v1.3 supports all final SRFIs except for those listed below. Some of the unsupported SRFIs may be supported in future versions of Larceny, but are listed below to make the list of unsupported final SRFIs complete.
Although Larceny provides SRFI 0 in R5RS mode, it must first be loaded via (require 'srfi-0). In R7RS/R6RS programs, SRFI 0 has been superseded by R7RS cond-expand.
Larceny does not support SRFI 4, mainly because the nonstandard lexical syntax of SRFI 4 never really caught on. (Of the 10 systems we tried, only Bigloo, Gambit, and Kawa support it.) The #u8(...) syntax for bytevectors was adopted by the R7RS and is fully supported in Larceny.
This SRFI describes a configuration language that's "entirely distinct from Scheme", but the R7RS provides similar features within Scheme.
Larceny does not support SRFI 10 because the R6RS requires #,... to be read as (unsyntax ...).
Although Larceny supports SRFI 14 and supports arbitrary character sets over full Unicode, the char-set-complement and char-set-complement! operations are deprecated because complementing a small character set yields a character set with over a million Unicode characters. As SRFI 14 notes, it is better to complement sets with respect to a smaller universe using char-set-difference.
Larceny does not currently support SRFI 18.
Larceny does not currently support SRFI 21.
Larceny no longer supports SRFI 22 because it interferes with the parsing of #!r6rs and similar flags. Use R6RS-style Scheme scripts instead, which are supported by Larceny's scheme-script.
Larceny does not support SRFI 34, which has been superseded by the R6RS and R7RS. Use R7RS-style exception handling instead.
Larceny does not support SRFI 35, which has been superseded by the R6RS (and, to some extent, by the R7RS as well). Use R6RS-style conditions or R7RS-style error objects instead.
Larceny does not support SRFI 36, which has been superseded by the R6RS (and, to some extent, by the R7RS as well). Use R6RS-style conditions or R7RS-style error objects instead.
Although Larceny supports SRFI 38, it has been superseded by the R7RS, which adopted its lexical syntax while integrating its operations into the standard read and write procedures.
Although Larceny supports SRFI 39, it has been superseded by the R7RS.
Larceny does not support SRFI 40, which has been superseded by SRFI 41.
Although Larceny supports SRFI 41, it has been superseded by the (scheme lazy) library of R7RS.
Larceny does not support SRFI 44. This SRFI was controversial from its proposal, partly because it appears to presuppose a companion SRFI that has not been finalized.
Larceny does not support SRFI 46, which has been superseded by the R7RS.
Larceny does not support SRFI 47, which has been superseded by SRFI 63 and SRFI 122.
Larceny does not support SRFI 49.
Larceny does not support SRFI 55. Larceny's autoloading of R7RS/R6RS libraries is a better (and ultimately more portable) solution to the problem addressed by SRFI 55.
Larceny does not support SRFI 58. Its nonstandard lexical syntax has not caught on. (Of the 10 systems we tried, only SCM supports it.)
Although Larceny supports SRFI 60, it has been superseded by a similar set of R6RS procedures, which are likely to run faster in Larceny. Use the procedures that are exported by the (rnrs arithmetic bitwise) or (srfi 151) libraries instead of SRFI 60.
SRFI 62 describes a feature that was adopted by both the R6RS and R7RS, and is supported by Larceny in all modes.
Although Larceny supports SRFI 66, octet vectors have been superseded by the R6RS and R7RS. Use bytevectors instead.
SRFI 69 has been superseded by SRFI 126 and the (scheme hash-table) library of R7RS Red Edition. Although Larceny supports SRFI 69, that SRFI contains several design errors and several inherent inefficiencies. For applications that require hashtables that are compatible with eq? or eqv? comparisons, we recommend R6RS hashtables, provided by (srfi 126) or (rnrs hashtables), because they are likely to be orders of magnitude more efficient than SRFI 69 hashtables. In Larceny, the R7RS-style hashtables of (scheme hash-table) are interoperable with R6RS-style hashtables, and we have made an effort to reduce (without completely eliminating) the inefficiency of R7RS-style hashtables compared to R6RS-style.
Larceny does not support SRFI 70, which has been superseded by the R6RS and SRFIs 143 and 144. Larceny's semantics for numbers is intended to be compatible with the R5RS, R6RS, and R7RS standards. All of those standards are incompatible with SRFI 70.
Although Larceny supports SRFI 71, we recommend using (let-values and let*-values) instead.
Larceny does not support SRFI 72, most of which has been superseded by the R7RS/R6RS macro systems. Use syntax-rules, syntax-case, or explicit-renaming macros instead.
Although Larceny supports SRFI 74, it has been superseded by the R6RS. Use bytevectors instead.
Larceny no longer supports SRFI 86. It is extremely complex, takes a long time to compile, and does not appear to have compelling advantages over the more standard mechanisms it simulates.
Although Larceny still supports SRFI 87, the extension it describes has been adopted by the R7RS.
Larceny does not support SRFI 88. Use symbols instead.
Larceny does not support SRFI 89, which presupposes the deprecated SRFI 88.
Larceny does not support SRFI 90, which presupposes the deprecated SRFIs 69, 88, and 89 while adding only one truly useful feature, weak references, which are the subject of SRFI 124 and will eventually be supported by Larceny's implementation of SRFI 126. Use R6RS-style hashtables instead, which are specified by both R6RS and SRFI 126.
Larceny does not support SRFI 94, parts of which have been superseded by R6RS standard libraries and SRFIs 143 and 144.
Although Larceny supports SRFI 95, its most important features have been superseded by an R6RS standard library, SRFI 132, and the (scheme sort) library of R7RS Red Edition.
SRFI 97 describes a naming convention. Larceny continues to support that naming convention for backward compatibility with R6RS libraries and programs, but it has been superseded by a simpler and more general naming convention made possible by the R7RS. SRFI 101 is the highest-numbered SRFI for which Larceny currently supports the SRFI 97 naming convention. For newer SRFIs, Larceny uses the R7RS naming convention (e.g. (srfi 115 regexp) located in a file named "srfi/115/regexp.sld" instead of (srfi :115 regexp) located in "srfi/%3a115/regexp.sls") and has extended the R6RS library syntax to allow importation of R7RS library names.
R6RS purists who say Larceny's more liberal import syntax violates an "absolute requirement" of the R6RS are entirely correct, and are invited to duplicate the code of every new SRFI library, renaming libraries as necessary to fit within the unpleasantly arbitrary restriction mandated by the R6RS.
Although Larceny continues to support SRFI 99, Larceny has extended the define-record-type syntax of R7RS (scheme base) to allow ERR5RS and R6RS syntaxes in addition to the syntax described by the R7RS. We recommend using the portable R7RS, SRFI 9, and SRFI 131 syntax where possible, using the more expressive ERR5RS syntax and ERR5RS procedural layers only when necessary.
Although Larceny continues to support R6RS records, and we have gone to considerable trouble to make the R6RS syntactic and procedural layers interoperable with more recent standards, we recommend against using R6RS records. The R6RS record layers are not even fully compatible with each other, so they will never be fully compatible with any extension of R6RS records.
Larceny does not support SRFI 100 or SRFI 105.
Larceny does not yet support SRFI 106.
Larceny does not support SRFI 107, SRFI 108, SRFI 109, or SRFI 110.
Although Larceny supports SRFI 114, it has been superseded by SRFI 128.
Larceny does not support SRFI 118 or SRFI 119.
Larceny does not yet support SRFI 120.
Although Larceny supports SRFI 130, it has been superseded by SRFI 135 and (scheme text), which is now part of R7RS Red Edition. In Larceny, the string cursors of SRFI 130 are the same as string indexes, but using the low-level operations on string cursors will be slower than using arithmetic operations on string indexes. SRFI 130 is deprecated because it promotes the idea that string cursors are faster than string indexes, which is just not true in Larceny and is unlikely to become true in most other native-code implementations of R7RS and R6RS Scheme.
Although Larceny supports SRFI 136, its record system is fundamentally incompatible with Larceny's implementation of the R7RS, R6RS, SRFI 9, SRFI 99, and SRFI 131 record systems.
Although Larceny supports SRFI 137, its primitive mechanisms are both redundant with and incompatible with the more sophisticated facilities provided by the R7RS, R6RS, SRFI 9, SRFI 99, and SRFI 131 record systems.
Larceny does not support SRFI 139.
Larceny does not support SRFI 140, which was proposed as an alternative to SRFI 135 for the R7RS Red Edition ballot. SRFI 135 was adopted, and became (scheme text) in R7RS Red Edition.
Although Larceny supports SRFI 142, it has been superseded by SRFI 151. According to SRFI 151, the only difference between these two SRFIs is the semantics of the bitwise-if procedure.
Although Larceny supports SRFI 147, it does not "properly" support SRFI 147 because the define-syntax, let-syntax, letrec-syntax, and syntax-rules exported from (srfi 147) are not the same as the versions exported from Larceny's implementation of (scheme base).
Larceny does not support SRFI 148, mainly because Larceny's R7RS/R6RS macro expander has performance bugs that make processing of extraordinarily macro-intensive libraries such as (srfi 148) painfully slow. If you're patient, the sample implementation of SRFI 148 does work in Larceny.
Larceny does not support SRFI 149. SRFI 149 describes an extension to the semantics of R7RS syntax-rules that is incompatible with the R6RS semantics of syntax-rules, which Larceny has supported for many years. (If SRFI 149 were an ordinary SRFI, Larceny could support it despite that incompatibility, but SRFI 149 effectively mandates a retrospective change to the R7RS (small) standard by requiring the syntax-rules exported by (scheme base) to behave as specified by SRFI 149. That would break some existing code. More importantly, it would make interoperation between R6RS and R7RS code considerably more awkward.)
SRFI 150 describes an alternative to SRFI 131 that is incompatible with the R7RS, R6RS, SRFI 9, SRFI 99, and SRFI 131 record systems as implemented in Larceny. If Larceny ever supports SRFI 150, it will be deprecated for its incompatibility with prior standards and existing code.