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

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

On Fri, 2013-01-04 at 13:41 +0900, Alex Shinn wrote:

> Although Aaron is correct that in the general case we can't single out
> the specific macros used, it is not impossible in all cases, and would
> therefore be wrong for the standard to forbid such optimizations.

[...]

> Assuming we don't want to add a long discussion of the definition of
> visitation for something that is fairly simple in the small language,
> I would suggest: 
> 
>     Similarly, during the expansion of a library {\cf foo}, if     any
> syntax keywords imported from another library {\cf (bar)}     are
> needed to expand the library, then the corresponding syntax
> definitions of {\cf (bar)} must be expanded before the     expansion
> of {\cf (foo)}. 

The problem with this definition and the one that John gave previously
is that you are not just expanding those definitions. The right hand
sides of syntax definitions must be expanded *and* evaluated, though we
only allow for syntax-rules at the moment. 

Also, while you are correct that there are some cases where it is not
necessary to expand the whole library in order to obtain the definition
of one keyword, I believe it is incorrect to say that this is an
optimization that can be implemented in practice. Namely, I submit that
the check to determine whether this optimization is safe is precisely
the process of expansion. That is, the optimization is only valid in
cases where the observational behavior between expanding the one syntax
definition required and expanding the whole syntax library are the same.
Thus, the optimization that we should permit is one that allows for
optimizing only in the case where thee is no observational different
between expanding the whole library and only some of the library. This
optimization is not forbidden by defining our semantics in terms of
library expansion instead of in terms of only a single definition being
evaluated, but by defining our semantics in this way, we do forbid the
unsafe optimization, which I think is a good thing. We should not
introduce that sort of ambiguous behavior into the standard, though it
is fine if an implementation wants to provide such an optimization as an
extension, it will be non-standard, but that's not a problem.

It should also be pointed out that the optimization in question is
different than the optimization of dead-code elimination. If a library
is used and a syntax definition is never used, and this can be proven,
then there is no need to include the syntax definition in a compiled
result, even *if* we have done an expansion of the library first. The
optimization mentioned above is one that dictates that the syntax
definition is never evaluated in the first place. 

To illustrate the point, consider two possibilities, one where there is
a syntax error that is generated, either intentionally or
unintentionally by expanding the library. However, suppose then that
this error is *not* triggered by evaluating the one syntax definition.
In this case, we have a situation where the observable behavior of
importing the library depends on our optimization level. Worse, if we
allow this interpretation in the standard then it means that we have no
real way of guaranteeing the behavior we want. Another case would be if
we introduce an infinite loop into the macro expansion; it is possible
that this library will only infinite loop in certain cases of library
imports, but not in others. 

To further go through this, consider the case where we introduce two
syntax definitions in the same library. This library should not expand
correctly, and we should not be able to use any of the syntax
definitions. However, if we allow this optimization it is possible to
hide one of the definitions inside of a macro expansion such that the
expansion will not run with this optimization turned on, and the
implementation will incorrectly provide a syntax definition to the
importing library when in fact the implementation should have signaled
an error. It is impossible to check for this case without first
expanding the library. There are certain cases where it may be possible
to provide that the library, for instance, is nothing but a series of
syntax definitions, with no other forms in it, and thus, you *can*
optimize the system by only loading what you want. In this case,
however, the operational behavior that we would see is equivalent to
having the library fully expanded, and thus, it would still be possible
to perform this optimization and preserve standard semantics even if we
defined these semantics in terms of a complete library expansion, rather
than a selective expansion.

So, I would propose the following language:

    Similarly, during the expansion of a library {\cf foo}, if
    any syntax keywords imported from another library {\cf (bar)}
    are needed to expand the library, then the library {\cf (bar)} 
    must be expanded and its syntax definitions evaluated before the
    expansion of {\cf (foo)}.

I have thought of all of this rather quickly, and it is rather late
here, so I hope someone will try to figure out where I have gone wrong
here. 

	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