[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Fixing libraries (was Re: Questions about cond-expand)
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
"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
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
> 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@x
hands thoroughly before going to the toilet. http://www.ccil.org/~cowan
Scheme-reports mailing list