[plt-scheme] define-values/invoke-unit in an internal definition context

From: Abdulaziz Ghuloum (aghuloum at cs.indiana.edu)
Date: Mon Oct 13 17:52:25 EDT 2008

On Oct 13, 2008, at 9:11 AM, Matthew Flatt wrote:

> Thanks very much for your note!

Sure thing.


> I must say that I was confused about this message for a while. I
> thought you meant that you incorrectly implemented the algorithm that
> Oscar defined. But from my earlier study of Oscar's system, I expected
> the examples above to behave in exactly the way that you claim is
> broken. The again, `petite' (v7.3) as well as `ikarus' (current from
> bzr) gave your predicted result.

Sorry about my confusing message.  You're right, Oscar's original
algorithm did not account for these exact marks.  Kent corrected
it later.


> It eventually dawned on me that someone fixed Oscar's algorithm  
> itself,
> perhaps since v6.9 of `petite' that I was using originally. You didn't
> say how the algorithm was fixed, but after a few more experiments, it
> was easy enough to guess: the expander takes a diff of the lexical
> context on the use of a module id compared to the binding of the
> module, and it applies that diff to the module's exported ids when
> they're unpacked by `import'. Sure enough, when I look at
> "psyntax.expander.ss", I see the diff-transferring operation in
> `module-interface-exp-id*'. And in "psyntax.ss" from Kent's page, I  
> see
> that `lookup-import-binding-name' acquired a new `new-marks' argument
> between versions 6.9 and 7.0.
>
> Is that all correct?

This is all exactly correct.  Since the module identifier (or the sig
identifier) may get extra marks from the point in which it was defined
to the point in which it is used, the identifiers that get pulled from
the module/signature record should behave as if they'd undergone the
same transformations (by acquiring the diff of the marks).


> You're completely right that the treatment of bindings with units was
> based on Oscar's (old) `module', and that's why we have the (old) bug.
> I will look into adding a context-diff-and-apply operation to PLT
> Scheme's macro system.

This may break some code that depends on the bug, but better to fix
it now than later.

Aziz,,,


Posted on the users mailing list.