At top level, ‘define’ in R7RS mode does not conform to the semantics decribed in section 5.3.1 of the report

[mnieper]

Larceny (in R7RS mode) raises the error Redefinition of identifier in body when given this program as input:

(import (scheme base))

(define x 1)
(define x 2)

According to R7RS, section 5.3.1, the second definition should have the same effect as (set! x 2).

Amongst things that R7RS actually forbids at the outermost level is redefining or mutating imported identifiers (section 5.2) or to define an identifier whose binding has to be known in order to determine the meaning of the definition itself (section 5.4). Whether this is correctly implemented at the top level cannot be determined as long as everything is shadowed by the error reported in this issue.

[WillClinger]

The problem here is that R7RS and R6RS top-level programs look exactly alike and are currently treated exactly alike, but they aren't exactly alike.

If they're going to continue to be treated exactly alike, then the R6RS semantics needs to be liberalized rather than limiting the R7RS semantics as is currently being done.

Another approach is to disambiguate using the mode.

[WillClinger]

Fixed by changeset 23bdea7cf556fc072b6da4f99f59af0e09aafeba

Larceny now disambiguates using the mode. This is less than ideal, because the disambiguation depends on the mode at expansion/compile time rather than run time. If an R6RS program is compiled by running Larceny's compiler in R7RS mode, which is the only easy way to pre-compile an R6RS program, the R7RS semantics will be used instead of the intended R6RS semantics. Conversely, if an R7RS program is compiled by running the compiler in R6RS mode, which is hard to do, the R6RS semantics will be used.

Disambiguating via the mode does work when running an R6RS or R7RS program that has not been pre-compiled.