Re: psyntax and compiler extension required

Scott Miller wrote:

> I vote for the above.  Its cleaner in the interpreter, as nothing needs 
> to be special cased within LetrecExp.

What kind of Exps we need in the interpreter is largely independent from 
what primitive syntax we introduce. For the syntax I prefer an extended 
letrec instead of letrec-values (ditto for let and let*, but these can 
be handled in the expander) since syntactically the multi-value case 
fits quite intuitively and neatly into the existing forms and that's 
what I'd like to see in R6RS. The explanation in R5RS of how internal 
definitions are handled would have to change only very slightly whereas 
having a separate letrec-values would result in a much more complex 
explanation (c.f. mzscheme docs ;).

> What we would need, then, is an
> MVLetrecEval to handle the assignment part of the letrec (note that 
> LetrecExp can remain unaffected).

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?

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.

> 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).


Matthias.



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge