[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "module" vs. "library"
On Tue, 5 Jul 2011, John Cowan wrote:
> Andre van Tonder scripsit:
>
>> Why is INCLUDE conflated with the module language? It is really an
>> orthogonal concept. INCLUDE as defined in Chez (e.g.) is just a
>> form (definable as a procedural macro) that can be used in any code,
>> including R6RS libraries.
>
> For one thing, the WG1 language does not have procedural macros, so you
> can't write your own version of `include`.
...which would be a good reason for including it as a form in the WG1 language.
> Alex has some pretty good arguments (which unfortunately he didn't
> include in his response) that generalized `include` is not all that
> useful. At the REPL, it is equivalent to `load`.
No, INCLUDE expands to a BEGIN form and so can occur anywhere a BEGIN can occur,
so you can use it to include code in any <body>, say, where it is not
equivalent to LOAD.
> In scripts, it leaves
> the question of what directory the included file is to come from open,
> making such scripts not very portable.
This is a poor reason either way, since your proposed usage
of INCLUDE in modules has exactly the same directory portability problem.
> In arbitrary lexical contexts,
> it would require the file to contain a single Scheme expression only.
No, because it wraps the file in a BEGIN.
> Indeed, we
> have provided `include-ci`, which permits the including of R5RS Scheme
> code that is case-insensitive into case sensitive R7RS systems, without
> in any way changing the code itself.
A case-folding INCLUDE-CI can just as easily be implemented as an ordinary
form.
> In the module language, however, providing `include` allows (without
> requiring) a separation of concerns, such that Scheme code files need
> contain no module cruft, and module files need contain no Scheme code.
> This seems to me extremely convenient as well as desirable.
Understood, but you can still have this separation of concerns if INCLUDE is a
form instead of part of the module language. On the Scheme code file side
there would be no difference. On the module side, the resulting module
boilerplate would look almost the same.
Many Schemes already have an INCLUDE form, so the current WG1 proposal would
effectively really be overloading INCLUDE if adopted in these implementations,
just like the proposal currently overloads BEGIN into the module language. That
is fine but a little ugly IMO.
Having INCLUDE (and BEGIN) in the module language also complicate the parsing
and implementation of modules. For schemes that have an INCLUDE form anyway,
you get to implement the same functionality essentially twice (parsing a
sequence), which violates the "once and only once" principle, for those who
care about such things.
Plus, traditional INCLUDE is nicely compositional. An INCLUDEd file can in turn
INCLUDE otehr files, ad nauseam. On the other hand, WG1 module-level INCLUDE is
not compositional. This is fine but, again, somewhat ugly IMO.
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports