[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] "module" vs. "library"

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.

> 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.

(Just being a little contrarian here, no substantive criticism.)


Scheme-reports mailing list