[plt-scheme] Units implementation: to access imports by indexes

From: Keiko Nakata (keiko at kurims.kyoto-u.ac.jp)
Date: Fri May 15 07:51:00 EDT 2009

Thanks a lot for the reply. 

> To a first degree of approximation, an import is represented as a vector 
> of boxes. The vector is unpacked in the unit body and hidden temporary 
> names are given to the boxes. The imported names are bound as macros 
> that expand into box accesses ('unbox') of the hidden names.

I think I can relate this basic picture to the implementation. But
my understanding is still shallow and I was worried that introducing
promises might interact with expansions of imported macros.
 
> If the box indirection were eliminated, then it would be impossible to 
> garbage collect unit-exported values independently: a closure that 
> referred to one imported name would keep all of them alive, because that 
> reference would really be a reference to the vector plus an index.
 
This is an interesting point to know, in particular to compare two
alternative implementations I have in mind (as explained below).

> Perhaps you should try changing the boxes to promises. Currently, only 
> definitions of exports are rewritten to use boxes, but you might need to 
> rewrite local (unexported) definitions to use promises too.
 
Since I want the evaluation order to agree with the textual definition
order unit-wise, i.e. members of a unit will be evaluated following
their definition order in the enclosing unit, I would need a little
more trick than simply wrapping all the local definitions into
promises.

I have been thinking two options. One is to use nested delayed pairs: 
 is enforced. 
"(define x1 e1) (define x2 e2) ..." would be translated into 
"(define x1 (delay e1)) (define x2 (delay e2)) ... (define x (delay (x1, (delay (x2, ...)))))" 

Then by exporting x and accessing a member by its corresponding
position in the nested pair, the evaluation order will respect the
textual definition order.

The other is to introduce a global constraint to control the
evaluation order, e.g. to store in a box a partial order on defined variables
which corresponds to the textual definition order and to consult the
partial order when forcing a variable.

The first approach pleases me. But the issue on GC, as you explained,
could be a disadvantage of it.

Kind regards,
Keiko


Posted on the users mailing list.