Re: psyntax and compiler extension required

On Sun, May 18, 2003 at 12:06:30PM +0100, Matthias Radestock wrote:
> 
> I see. So the multi-value rand that binds (foo bar baz) would stuff the 
> result into the vlr pos for foo, and MVLetrecEval would take that value 
> apart and stuff the parts into the vlr positions for foo, bar, baz?

The way Letrec's are evaluated is that a LetrecExp creates the 
environment which will eventually hold the values, then defers to an 
AppExp (its superclass), which pretends to evaluate a bunch of rands.  
Then, rather than an AppEval, a LetrecEval copies the VLR into those 
environment slots.  So, for a multiple values letrec, we would just 
create n more environment slots, which LetrecExp doesn't even need to 
know will be filled with multiple values.  The one difference is that 
LetrecExp would need to create the environment based on a size we 
specify from the compiler, rather than the length of rands.  Example:

(letrec ([a 1] [b 2]) (+ a b))
results in roughly:

LetrecExp creates a 2 element env
AppExp and friends load vlr with (1, 2)
LetrecEval stores vlr->env, throws (+ a b) into the nxp

(letrec ([(a b) (values 1 2)] [c 1]) (+ a b c))
LetrecExp creates a 3 element env
AppExp and friends load vlr with ({1, 2}, 3)
MVLetrecEval recognizes sisc.data.Values instances (possibly constructed 
  this way from the Compiler), and copies them into successive env 
  slots, then loads (+ a b c) into nxp

> MVLetrecEval would have to be given information on what vlr positions to 
> expand and how many values to expect for each. That could just be a 
> number array of size exprs.length (i.e. the number of binding 
> expressions) with the numbers indicating how many values to expect.

Yes.  The compiler should be able to easily do this.

> >If we want to support toplevel define-values, we don't really need any 
> >native support, as we *should* be able to write a macro that does the 
> >following:
> 
> yes, it's in the FAQ ;), except ...
> 
> >We would obviously need expander support for an internal define-values.
> 
> which is why you *cannot* define the top-level define-values as a macro. 
> If the top-level define-values is "just a macro like any other" the 
> expander would have no way of knowing that it is not applicable in 
> internal definitions unless the expander just *assumed* that (which 
> would be wrong since a user may redefine define-values and expect it to 
> apply to both top-level and internal definitions).

True.  

	Scott

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+x6Uhr9IW4v3mHtQRAr9MAKCRnjae6yF3No9NWpJAnYdnLHElhwCeOTca
pALJZGq6621eewfMimtmD18=
=uCfl
-----END PGP SIGNATURE-----