[plt-scheme] function `eval-compile-time-part-of-top-level'

From: John Clements (clements at brinckerhoff.org)
Date: Thu Jan 9 11:38:06 EST 2003

On Wednesday, January 8, 2003, at 10:12  PM, Guillaume Marceau wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>
> Hello everybody,
>
> I am trying to build an error checker in the style of the DrScheme
> Check Syntax tool.
>
> Inspiring myself from syncheck.ss, I was able to add my own button to
> the button bar. I am now trying to understand the 100 lines or so, in
> the body in the `button-callback' function, that sets up the code-text
> expansion.
>
> In there, there is a call to `eval-compile-time-part-of-top-level'
> whose purpose eludes me. What does it do? What is it for?
>
> The documentation says :
>
> "
>   (eval-compile-time-part-of-top-level syntax) : evaluates
>   expansion-time code in the fully expanded top-level expression
>   represented by `syntax' (or a part of it, in the case of `begin'
>   expressions). The expansion-time side might affect the compilation
>   of later top-level expressions. For examples, if `syntax' is a
>   `require' expression, then `namespace-require/expansion-time' is used
>   on each require specificcation in the form. Normally, this function
>   is used only by `expand-top-level-with-compile-time-evals'
> "
>
> I am not sure I understand the issue being discussed here. Plus, the
> last sentence more or less says this function should not be
> used.

This is an important issue for you, if you're building a syntax checker.

The deal is this: presumably, you're doing syntax checking on the 
expanded source.  That is, you're going to run some flavor of 'expand' 
before you try to check the syntax.  This is more or less necessary, 
because there's no way of knowing, before expansion, what syntactic 
language you're checking.  Each `language' specification (at the top of 
a module) defines a different one, and requiring libraries may also 
change the language that you're checking.  The `expand' functions solve 
this problem by translating all programs into a fixed syntactic 
language which is documented in the MzScheme manual.

Well, okay, that's fine, but what's this special function?

The problem is that DrScheme inherits from time immemorial the notion 
of the 'top level', which has a funny problem.  In a Scheme top level, 
the assumption is that you evaluate each expression before expanding 
the next one.  This is true even when you click "execute" on a 
definitions buffer which contains a bunch of top-level expressions.  As 
a result, if your definitions window contains expressions A and B, it's 
incorrect to expand B before executing A, because evaluation of A might 
change the language.

This is a big problem for a syntax checker.  The syntax checker wants 
to expand _all_ the expressions, but doesn't want to evaluate any of 
them.  How to solve this?  Well, it turns out that the syntactic 
structure of PLT scheme is designed to be able to separate 
expansion-time code from evaluation-time code (in fact, this separation 
induces a tower of evaluation times).  With this separation, mzscheme 
provides a way to evaluate the expansion-time code associated with an 
expression (say, a syntactic extension) from the evaluation-time code 
associated with an expression.  The 
(eval-compile-time-part-of-top-level syntax) call performs this 
evaluation.

When all is said and done, though, my guess is that from your 
standpoint, the only change to your code will be that you call 
`expand-top-level-with-compile-time-evals' instead of whatever other 
flavor of `expand' you're currently using.

hope this helps (and is vaguely correct),

john clements




Posted on the users mailing list.