[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
need them.


Scheme-reports mailing list