[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "module" vs. "library"
On Wed, Jul 6, 2011 at 6:59 AM, Andy Wingo <wingo@x> wrote:
> On Tue 05 Jul 2011 16:19, Alex Shinn <alexshinn@x> writes:
>> The rationale is that we want room for future extensions -
>> e.g. the ability to have an import-lazy declaration (i.e. autoload),
>> or first-class interfaces and units, or versioned libraries, etc.
> Unless I misunderstand, Ghuloum & Dybvig's implicit phasing effectively
> provides for autoloads, without having autoloads mentioned explicitly
> anywhere in the spec.
Well, that was just one example, and while we can allow
implicit phasing I don't think we can require it in the standard,
much less require compilers be clever enough to load lazily.
>> These are all things which must be handled at the module
>> level, so imported syntax is not an option. However, the
>> R6RS module system is very rigid. A module takes the
>> exact form of
>> (library name (export ...) (import ...) body ...)
>> which leaves no room extension. For example, if you
>> simply declare that import-lazy is a new optional form
>> that can occur at the beginning of the body, it conflicts
>> with any existing uses of import-lazy.
> I understand the argument, but it has its counterpoint: it is impossible
> to add a binding to any module, or indeed any module to any spec, for
> fear that it collides with an already existing module or binding.
Yes, but the module keywords in R6RS are "extra special" -
you can't use only/except/rename to filter them out when you don't
Scheme-reports mailing list