Re: [Scheme-reports] "module" vs. "library" Denis Washington (04 Jul 2011 18:02 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (05 Jul 2011 00:39 UTC)
Re: [Scheme-reports] "module" vs. "library" Andre van Tonder (05 Jul 2011 01:31 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (05 Jul 2011 04:06 UTC)
Re: [Scheme-reports] "module" vs. "library" Denis Washington (07 Jul 2011 16:06 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (07 Jul 2011 17:53 UTC)
Re: [Scheme-reports] "module" vs. "library" Denis Washington (07 Jul 2011 18:30 UTC)
Re: [Scheme-reports] "module" vs. "library" Alaric Snell-Pym (08 Jul 2011 09:49 UTC)
Re: [Scheme-reports] "module" vs. "library" Denis Washington (08 Jul 2011 10:13 UTC)
Re: [Scheme-reports] "module" vs. "library" Alaric Snell-Pym (08 Jul 2011 10:46 UTC)
Re: [Scheme-reports] "module" vs. "library" Eli Barzilay (08 Jul 2011 14:16 UTC)
Re: [Scheme-reports] "module" vs. "library" Aaron W. Hsu (05 Jul 2011 04:46 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (05 Jul 2011 04:53 UTC)
Re: [Scheme-reports] "module" vs. "library" Andre van Tonder (05 Jul 2011 13:47 UTC)
Re: [Scheme-reports] "module" vs. "library" Alex Shinn (05 Jul 2011 14:20 UTC)
Re: [Scheme-reports] "module" vs. "library" Andy Wingo (05 Jul 2011 22:01 UTC)
Re: [Scheme-reports] "module" vs. "library" Alex Shinn (05 Jul 2011 23:21 UTC)
Re: [Scheme-reports] "module" vs. "library" Eli Barzilay (06 Jul 2011 03:33 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (05 Jul 2011 17:11 UTC)
Re: [Scheme-reports] "module" vs. "library" Andre van Tonder (05 Jul 2011 22:07 UTC)
Re: [Scheme-reports] "module" vs. "library" Alex Shinn (05 Jul 2011 23:22 UTC)
Re: [Scheme-reports] "module" vs. "library" John Cowan (08 Jul 2011 03:31 UTC)

Re: [Scheme-reports] "module" vs. "library" Alex Shinn 05 Jul 2011 23:20 UTC

On Wed, Jul 6, 2011 at 6:59 AM, Andy Wingo <wingo@pobox.com> wrote:
> 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.

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.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports