[r6rs-discuss] Import choices: flexibility vs. discoverability

[John Cowan]

Aaron W. Hsu scripsit:

> My use of the term syntactic modules is meant to distinguish the ability  
> to generate modules from macros from module systems that in essence exist  
> at a level different than othere Scheme code, such that Scheme code can  
> not naturally manipulate or work with module forms directly. R6RS  
> libraries are an example of libraries that cannot be treated in this  
> manner.

I see.  Thanks for the explanation.  (This is an example of why I'm still
using module rather than library as the keyword: I think it's very bad to
reuse a standardized keyboard with a new and different semantics.)

> I also believe that modules should be valid anywhere a definition  
> is valid. This is a direct result of the syntactic thinking. That is, I  
> see modules as just another Scheme form, not as a separate language.

But not as a first-class run-time object like strings or procedures, then.

> Most of the Scheme implementations I am seeing use separate files rather  
> than cond-expand to do this sort of glueing. I'm inclined to think that  
> this is the way to go, and that neither of these is suitable to put in the  
> Core Scheme. I just don't see enough of cond-expand in widespread use.

It's rather widely implemented (20 out of 28 Schemes); I find it hard
to believe that nobody uses it.

> Maybe we can define cond-expand somewhere else and say that  
> modules defined should have a cond-expand element registered, but that's  
> in the specification of cond-expand, not modules.

Indeed; as you'll see, my http://tinyurl.com/thing-one basic proposal
incorporates cond-expand with SRFI 0 semantics, which I extend by saying
that "modules defined should have a cond-expand element registered".

-- 
John Cowan  cowan at ccil.org  http://www.ccil.org/~cowan
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
        --blurb for Rikki-Kon-Tiki-Tavi