[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "module" vs. "library"
Andre van Tonder scripsit:
> 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.
I was speaking of the top level of the REPL. But you're quite right about
expanding to a `begin`; I had overlooked that.
> This is a poor reason either way, since your proposed usage of INCLUDE in
> modules has exactly the same directory portability problem.
An implementation controls where the modules are stored, and will be
able to use an appropriate mapping convention (look in the same
directory as the module, or whatever). Scheme scripts could be anywhere
on the system, and will be hard to move about if their include files have
to go with them.
> A case-folding INCLUDE-CI can just as easily be implemented as an
> ordinary form.
To be sure.
> 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.
If `include` is a regular part of Scheme, that means it can be generated
by a macro, which means that static analysis of modules is not possible.
> 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.
For static analysis, non-compositionality is an advantage.
John Cowan http://ccil.org/~cowan cowan@x
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash,
The day and hour soon are coming / When all the IT folks say "Gosh!"
It isn't from a clever lawsuit / That Windowsland will finally fall,
But thousands writing open source code / Like mice who nibble through a wall.
--The Linux-nationale by Greg Baker
Scheme-reports mailing list