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.
Source for ticket #132
cc
changetime
2012-10-07 12:12:08
component
WG1 - Modules
description
In R6RS and therefore in our current module system, you can't import the same name from two different places. I think we should consider changing this so that you can `(import (foo))` and then `(import (override))`, where `(override)` contains a subset of the names defined in `(foo)`. Otherwise you have to say `(import (except (foo) this that)`. This is no doubt safer, but also more annoying.
There are two sub-issues: allowing this at the REPL and/or allowing it in modules.
id
132
keywords
milestone
owner
alexshinn
priority
major
reporter
cowan
resolution
wontfix
severity
status
closed
summary
Imports override previous imports?
time
2011-01-22 08:45:28
type
defect
Changes
Change at time 2012-10-07 12:12:08
author
cowan
field
comment
newvalue
Nothing to be done here.
oldvalue
12
raw-time
1349586728723981
ticket
132
time
2012-10-07 12:12:08
Change at time 2012-10-07 12:12:08
author
cowan
field
resolution
newvalue
wontfix
oldvalue
raw-time
1349586728723981
ticket
132
time
2012-10-07 12:12:08
Change at time 2012-10-07 12:12:08
author
cowan
field
status
newvalue
closed
oldvalue
writing
raw-time
1349586728723981
ticket
132
time
2012-10-07 12:12:08
Change at time 2011-07-10 20:34:20
author
alexshinn
field
comment
newvalue
oldvalue
11
raw-time
1310304860000000
ticket
132
time
2011-07-10 20:34:20
Change at time 2011-07-10 20:34:20
author
alexshinn
field
status
newvalue
writing
oldvalue
decided
raw-time
1310304860000000
ticket
132
time
2011-07-10 20:34:20
Change at time 2011-07-10 18:04:33
author
alexshinn
field
comment
newvalue
We voted this is an error.
oldvalue
10
raw-time
1310295873000000
ticket
132
time
2011-07-10 18:04:33
Change at time 2011-07-10 18:04:33
author
alexshinn
field
resolution
newvalue
oldvalue
raw-time
1310295873000000
ticket
132
time
2011-07-10 18:04:33
Change at time 2011-07-10 18:04:33
author
alexshinn
field
status
newvalue
decided
oldvalue
new
raw-time
1310295873000000
ticket
132
time
2011-07-10 18:04:33
Change at time 2011-01-24 06:49:18
author
arcfide
field
comment
newvalue
I object to making order appear to matter when it does not; I do not object to the use of ordering freedom to produce more readable code. Nonetheless, if you really want something like you say, then you ought to appreciate the full flexibility of a syntactic module language, which we do not have in WG1. In such a system, where `export` is just another form, implementing `define/exported`, which is a trivial macro, is better than the workaround you have suggested.
oldvalue
9
raw-time
1295822958000000
ticket
132
time
2011-01-24 06:49:18
Change at time 2011-01-24 06:34:06
author
cowan
field
comment
newvalue
/me shrugs.
As a matter of style, imports should be bubbled to the top even if the syntax doesn't demand it. But interspersing exports with code bodies makes sense to me. (Hey, I like the Java style of tagging every definition as public or private.)
oldvalue
8
raw-time
1295822046000000
ticket
132
time
2011-01-24 06:34:06
Change at time 2011-01-24 06:21:30
author
arcfide
field
comment
newvalue
We have not bettered R6RS here, we have merely changed the syntax. Consider the following:
{{{
(library
(code ...)
(import ...)
(include ...)
(import ...)
(code ...))
}}}
Assume the semantics you describe, then the above code contains some forms where order matters intermingled with some that do not. It matters in what order the `code` and `include` forms appear, but it does not matter where the `import` forms appear. I can see only one useful situation for this behavior: if we could expand into `library` forms, then it would be easier to write such macros, because we need not collect all the code before we insert some of it into the final expanded `library` form. We cannot expand into library forms; allowing this in WG1 gains us nothing but potential confusion.
On the other hand, such independence and partial ordering might make sense in WG2, and I would like to consider it there.
oldvalue
7
raw-time
1295821290000000
ticket
132
time
2011-01-24 06:21:30
Change at time 2011-01-23 12:19:59
author
cowan
field
comment
newvalue
Not ordering the module declarations is fine; I'm now convinced that this ticket's proposal doesn't make sense in modules. Only allowing one code ''body'', in the name of not having to concern yourself with how they are ordered, is absurd overkill.
The definitions in the bodies are order-independent anyhow, since you are not allowed to define an identifier more than once in all the bodies. So all that's left is the random expressions in the bodies, and ordering the bodies in the module controls how their execution is ordered. Otherwise, you're no better off than with R6RS and its single implicit body.
oldvalue
6
raw-time
1295756399000000
ticket
132
time
2011-01-23 12:19:59
Change at time 2011-01-23 08:16:36
author
arcfide
field
comment
newvalue
Ignoring REPL interactions, ModulesShinn already makes implicit shadowing in modules illegal. Moreover, I believe it a mistake to imply any sort of ordering on the module declarations, which implies that we should not allow more than one body or include form.
oldvalue
5
raw-time
1295741796000000
ticket
132
time
2011-01-23 08:16:36
Change at time 2011-01-23 02:51:14
author
cowan
field
comment
newvalue
Au contraire. We have already accepted imports overriding previous imports at the REPL per ModulesShinn. The question now is whether to change ModulesShinn so that imports into a module can override previous imports into that module. The case against it is that it makes the final result hard to predict; the case for it is improved convenience.
oldvalue
4
raw-time
1295722274000000
ticket
132
time
2011-01-23 02:51:14
Change at time 2011-01-22 14:37:18
author
arcfide
field
comment
newvalue
Okay, I see the section on the REPL interactions, but I also see: “It is a syntax error if the same identifier is imported twice, from any combination of modules or multiple import forms.” This is for the module form. Moreover, ModulesShinn does not define an import form that is accessible in code. It is purely an element of the library form itself, so this question cannot apply to anything but the REPL unless we wish to introduce local imports.
oldvalue
3
raw-time
1295678238000000
ticket
132
time
2011-01-22 14:37:18
Change at time 2011-01-22 14:07:51
author
cowan
field
comment
newvalue
Actually it is specified there; see the section on REPL Interaction. You'll note that it provides for overriding, so the remaining part of this ticket is whether the same can be done within a module.
oldvalue
2
raw-time
1295676471000000
ticket
132
time
2011-01-22 14:07:51
Change at time 2011-01-22 12:13:32
author
arcfide
field
comment
newvalue
This requires that IMPORT be a normal form, which is not specified by ModulesShinn. What ticked deals with this issue?
oldvalue
1
raw-time
1295669612000000
ticket
132
time
2011-01-22 12:13:32