Skip to content
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

In R7RS programs, right hand sides of definitions are expanded too late #825

Open
mnieper opened this issue Oct 7, 2018 · 2 comments
Open

Comments

@mnieper
Copy link

mnieper commented Oct 7, 2018

Consider the following program:

(import (scheme base)
        (scheme write))

(define-syntax foo (syntax-rules () ((foo) 1)))
(define x (foo))
(define-syntax foo (syntax-rules () ((foo) 2)))
(display x)
(newline)

When Larceny runs this program, it outputs 2. This violates section 5.4 of the R7RS, which says:

If the define-syntax occurs at the outermost level, then the global syntactic environment is extended by binding the keyword to the specified transformer, but previous expansions of any global binding for keyword remain unchanged.

This means that the first binding of the keyword foo must be used where x is defined. Larceny, however, seems to defer the expansion of the right hand sides until all definitions have been processed.

The R7RS seems to be fundamentally incompatible to the R6RS here. In R6RS, the expansion of the right hand sides have to be deferred because the following is a valid R6RS program.

(import (rnrs base)
        (rnrs io simple))

(define x (foo))
(define-syntax foo (syntax-rules () ((foo) 2)))
(display x)
(newline)

It is unclear whether this deviation to the R6RS was a deliberate choice by the R7RS authors or accidental.

Expanding top-level programs with the R7RS semantics may need two passes over the definitions (where R6RS just needs one).

@WillClinger
Copy link
Member

Ouch.

Two passes would be problematic for programs that use syntax-case or other procedural macros. This incompatibility with R7RS may not be important enough to justify breaking R6RS code.

@mnieper
Copy link
Author

mnieper commented Dec 30, 2018

Caching may be possible so that macros are not expanded twice.

The R6RS semantics seem to be clearer (and easier to implement), so one can hope that a future addendum to the R7RS restores compatibility with the R6RS.

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

No branches or pull requests

2 participants