Re: [Scheme-reports] Questions about cond-expand John Cowan (05 Sep 2012 06:43 UTC)
Re: [Scheme-reports] Questions about cond-expand Alex Shinn (05 Sep 2012 08:14 UTC)
Re: [Scheme-reports] Questions about cond-expand John Cowan (06 Sep 2012 04:29 UTC)
Re: [Scheme-reports] Questions about cond-expand Alex Shinn (06 Sep 2012 04:34 UTC)
Re: Questions about cond-expand John Cowan (06 Sep 2012 04:46 UTC)
Re: [Scheme-reports] Questions about cond-expand Alex Shinn (06 Sep 2012 05:06 UTC)
Re: [Scheme-reports] Questions about cond-expand John Cowan (06 Sep 2012 05:42 UTC)
Re: [scheme-reports-wg1] [Scheme-reports] Fixing libraries (was Re: Questions about cond-expand) Aaron W. Hsu (07 Sep 2012 03:23 UTC)
Re: [Scheme-reports] Questions about cond-expand Aaron W. Hsu (06 Sep 2012 12:31 UTC)

Re: [scheme-reports-wg1] [Scheme-reports] Fixing libraries (was Re: Questions about cond-expand) Aaron W. Hsu 07 Sep 2012 03:24 UTC

Alex Shinn <alexshinn@gmail.com> wrote:

> What you are arguing below amounts to "let's just
> use the Chez module system."  We had a huge
> amount of discussion about this already and a fair
> vote, and the result is the only sensible possibility -
> a lowest common denominator module system.
> Chez modules cannot be implemented by every
> other system, nor can Scheme48 modules, but
> the R7RS define-library form can.

This is *not* what I am suggesting. I am not suggesting that we
change or alter any of our previous votes. I am not suggesting that
we alter or change the semantics that we voted on for the library
system. I am not suggesting that we use Chez Scheme's module system.

What I am suggesting is a rewriting of the language that we use to
define these semantics. This change of language results in a system
that is not different in terms of implementability on various
Schemes. It does address the confusions that have already arisen
multiple times about the various forms that we want in the language,
by unifying each form to a single form and a single definition. It
does eliminate the ambiguity introduced accidently by the specific
tickets in question by providing a clear, simple behavior for the
specific case of the top-level, while not precluding the direct
implementation of the normal forms that might appear in any
Scheme source. In other words, it fixes the problems introduced by
new terminology and inconsistent wording from the way that we
currently define the semantics of the library system. It does this
by leveraging existing Scheme concepts in the standard, rather than
introducing new ones.

The fixes that I am suggesting do *not* change the semantics or features
of our library system. The system is still implementable with a variety
of techniques, including static translation to an other, existing
system. All I am suggesting is that we fix the wording in a clean
way, and I gave a specific way that addresses all of the issues
that have come up, it does this without nullifying or overturning
any of our previous votes. It does not make our system less useful,
and it does not present any barriers as far as I read it to implementation
uptake, because it does not prescribe any implementation strategy.
Indeed, I have explicitly chosen the changes that I suggested because
they preserve the least common denominator semantics that I think are
important for WG1.

--

Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.