Re: [Scheme-reports] library syntax: "visiting" a library left undefined?

["Aaron W. Hsu" <arcfide@x>]

On Thu, 2013-01-03 at 13:24 -0500, John Cowan wrote:
> To remove the technical term, I have rewritten the sentence as
> follows:
> 
>   Similarly, during the expansion of a library {\cf foo}, if a syntax
>   keyword imported from another library {\cf (bar)} is needed to
> expand
>   the library, then the syntax definition of the keyword must be
> imported
>   from {\cf (bar)} before the expansion of {\cf (foo)}.
> 
> I hope this is the truth, since this is not a part of the spec I
> understand very well. 

I think this is not quite right. While technically true, it does not
give the guarantees that are actually in place. Specifically, when a
syntax keyword is required by an importing library the exporting
library's syntax definitions must be evaluated. That includes all of
them, not just the one that we care about. In common practice, with
richer library systems, the issue of phasing becomes important here,
because you may have macros that are used within macros and the like.
Since we effectively have only two phases (expand-time and run-time),
and we really don't even have the ability to execute arbitrary code at
expand-time, the issue is simplified. On the other hand, the
introduction of cond-expand and the like makes the situation a little
more complicated, because we now have some process on top of code
evaluation, which is something like library expansion, where we need to
see what code will actually be run.

In all, I think the main point here is that visiting is distinct from
completely evaluating the library. If one requires only the syntax of a
library, then all that is required is a visit, and it is possible that
the library need not be fully evaluated/instantiated. Thus, there are
three distinct levels of library "examination" which can yield
progressively more information:

1) Evaluation of the library forms, but not the arbitrary code bodies of
those forms, giving you information on the imports and exports of the
library, and gives a specific code body for the following steps, based
on the results of cond-expand;

2) Visitation, which gives you definitions of the keywords in the
library, but does not evaluate any of the code. This is akin in some
systems to expansion; and finally,

3) Instantiation, which evaluates the code definitions and binds their
exports, as well as evaluating the forms in the body that are found.

Since we have a system that does not have a full-featured macro system,
and because we do not have phasing per se, it is tempting to say that
one need only evaluate the definition of the syntax keyword that is
necessary for the importing library. I would submit that this is not
actually possible in general, however. In particular, it is impossible
to know the body of a syntax definition, or even whether a binding is or
is not a syntax definition without first expanding the library body.
Thus, one cannot separate out, in the general case, the expansion of a
library body from a single keyword export. Thus, the real guarantee here
is that the body of the library is expanded and all keyword definitions
evaluated during visitation, before the keyword is used in the importing
library. This is an important distinction semantically, as it
fundamentally alters the observable behavior of importing and using a
library keyword export.

I hope that clarifies things. 

	Yours truly,

		Aaron W. Hsu

-- 
Aaron W. Hsu | arcfide@x | http://www.sacrideo.us
לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃


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