Re: [Scheme-reports] "module" vs. "library"
Andy Wingo 05 Jul 2011 21:59 UTC
On Tue 05 Jul 2011 16:19, Alex Shinn <alexshinn@gmail.com> 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.)
Andy
--
http://wingolog.org/
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports