Terminological note:  The term "top-level" is IMO very unhelpful, as it is
too heavily overloaded.  Therefore I'm going to talk about "at the REPL",
"in a program", and "cannot be nested" instead.  If other people would
avoid "top-level" that would be helpful.

Aaron W. Hsu scripsit:

> 1. Define library as just another Scheme form that creates a close
> world.

"Form" is a very vague term.  Is define-library going to be an
expression, a definition, or a sui generis thing that can't be nested?
This matters, because definitions can only appear in a subset of places
where expressions can appear.  (The term doesn't appear in R5RS, any
earlier RnRS, or R7RS-draft, and the R6RS definition is vague too:
"a syntactic part of a Scheme program".)

> Making this change immediately removes the need to think about the
> library form as a static thing separate from the rest of the Scheme
> world. However, it still makes it a top-level, static form that is
> open to analysis.

By "top-level" do you mean "can't be nested", or simply that its meaning
doesn't depend on its context?

> 2. Define 'include', 'import', and the other forms as regular Scheme
> forms

Again, what are "regular scheme forms"?  Are they expressions,
definitions, or sui generis?

> [...] (let () (import ...) ...) and the like.

This could be either a definition or an expression, it's not clear.
If imports are expressions, are you allowed to say things like `(if
(x) (import (a)) (import (b))`?  I hope not.  That would conflate
`cond-expand` with `cond` and thoroughly entangle compile time with
runtime.

> 4. Unify the top-level of files and REPL to have at the minimum the
> 'library' and 'import' forms. This is all that is needed

`Import` is certainly required, but so is `cond-expand`, so so a program
can import different things depending on what libraries or implementation
features are available.  It's fine (and important for static conversion)
that neither can be nested.  Adding `include(-ci)` simplifies more
casual programming styles by allowing file-level modularity without
requiring library modularity.  Those are precisely the things (along with
expressions and definitions, once you have imported suitable identifiers)
that appear as "program parts" in 5.1; note that program parts are
provided not only in programs but at the REPL, providing there is one.

> 5. We can create a separate (scheme libraries) library to hold these
> forms, so that they need not pollute the user level code unless the
> user wants them. This is not necessary, but could be a nice separation
> of features.

By saying they can't be nested (because they are neither expressions nor
definitions) we achieve this while not dragging the question of run-time
conditional import or include on our heads.

--
Yes, chili in the eye is bad, but so is your    John Cowan
ear.  However, I would suggest you wash your    cowan-PrmTNUR8zL8@public.gmane.org
hands thoroughly before going to the toilet.    http://www.ccil.org/~cowan
        --gadicath