"Larceny is R6RS-compatible but not R6RS-conforming. When Larceny is said to support a feature of the R6RS, that means the feature is present and will behave as specified by the R6RS so long as no exception is raised or expected. Larceny does not always raise the specific conditions specified by the R6RS, and does not perform all of the checking for portability problems that is mandated by the R6RS. These deviations do not affect the execution of production code, and do not compromise Larceny’s traditional safety."
I think that's the right target to aim for.
The first and third arguments of bytevector-copy! are destination and source in R7RS, source and destination in R6RS. This is the only procedure that prevents you from importing all the R7RS-small and R6RS libraries together. Larceny by default imports the R6RS version as r6rs:bytevector-copy!.
It's possible to write a macro that supports both R6RS and R7RS syntaxes for define-record-type.
The discrepancy in error can be resolved at run time by checking if the first argument is a symbol or a string.
The functions integer?, rational?, and real? provide different results in R6 and R[457] on inexact complex numbers whose imaginary part is inexact zero. However, the R7 semantics are available in R6 under the names integer-valued?, rational-valued?, and real-valued?.
library and define-library modules have different syntax and different capabilities.
This list may not be complete. It should be compared with Akku's one-way R6->R7n conversion.
lassik
commented
4 years ago
This comes from "R7RS Considered Unifier of Previous Standards" by Will Clinger, which describes Larceny's R6/R7 integration. Here's a useful introduction:
"Larceny is R6RS-compatible but not R6RS-conforming. When Larceny is said to support a feature of the R6RS, that means the feature is present and will behave as specified by the R6RS so long as no exception is raised or expected. Larceny does not always raise the specific conditions specified by the R6RS, and does not perform all of the checking for portability problems that is mandated by the R6RS. These deviations do not affect the execution of production code, and do not compromise Larceny’s traditional safety."
I think that's the right target to aim for.
The first and third arguments of
bytevector-copy!are destination and source in R7RS, source and destination in R6RS. This is the only procedure that prevents you from importing all the R7RS-small and R6RS libraries together. Larceny by default imports the R6RS version asr6rs:bytevector-copy!.It's possible to write a macro that supports both R6RS and R7RS syntaxes for
define-record-type.The discrepancy in
errorcan be resolved at run time by checking if the first argument is a symbol or a string.The functions
integer?,rational?, andreal?provide different results in R6 and R[457] on inexact complex numbers whose imaginary part is inexact zero. However, the R7 semantics are available in R6 under the namesinteger-valued?,rational-valued?, andreal-valued?.libraryanddefine-librarymodules have different syntax and different capabilities.This list may not be complete. It should be compared with Akku's one-way R6->R7n conversion.