New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mnieper opened this Issue Jun 16, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@mnieper

mnieper commented Jun 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@WillClinger

WillClinger Jun 17, 2016

Member

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.

Member

WillClinger commented Jun 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@WillClinger

WillClinger Jul 1, 2017

Member

Fixed by changeset 23bdea7

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.

Member

WillClinger commented Jul 1, 2017

Fixed by changeset 23bdea7

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.

@WillClinger WillClinger closed this Jul 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment