This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 48: let-syntax

2011-01-24 07:00:19
WG1 - Macros
2010-04-06 08:28:06

Let-syntax has known ambiguities in its behavior. We have the option of altering its semantics to correct this behavior, defining which behavior we intend, or removing let-syntax entirely. We could also leave this ambiguity in there. ModulesAndPackagesArcfide suggests that let-syntax be removed in favor of the module syntax.

I do not believe it is a good idea to leave let-syntax with the ambiguous semantics that we currently have, especially considering that there are three different interpretations that are not clearly superior to one another. In order to fix this, we could specify a single interpretation, but this doesn't make sense given that there is no really better choice than the others. We could revert the splicing nature of let-syntax into an unsplicing form, but this removes an useful feature from let-syntax.

Regardless, since I do not believe we can leave the semantics as they are, if we fix let-syntax we will be breaking it in some fashion. This breaks backwards compatibility with some Scheme implementations. Given this, the clearer and more nicely defined semantics of the module syntax mentioned in ModulesAndPackagesArcfide seems to be a better approach, and provides the same expressiveness while being easier to use and less ambiguous. It also has the advantage of being a part of the module system.

I should also mention that strictly speaking, the module syntax is more expressive as a construct.


WG1 chose to make let-syntax a lexical contour.