[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Jan 4, 2013 at 2:17 PM, Aaron W. Hsu <arcfide@x> wrote:
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.

Well, generally expansion of a top-level define-syntax is equivalent to
its evaluation.  I'm fine with explicitly adding that they are evaluated,
as you suggest in your change below.   I dislike using the term "loaded"
here.
 
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.

I disagree.  There's the trivially simple optimization of lazy
expansion - not expanding lambda bodies until they are
applied.
 
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.

Then "it an error" and implementations are free to perform whatever
optimizations they want.
 
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.

This looks fine to me.

-- 
Alex

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