On Tue, Feb 24, 2009 at 1:40 PM, Per Bothner <[email protected]> wrote: > Sam TH wrote: >> >> Thinking about this a little more, it seems like it would run into >> some trouble with `local-expand' [1,2]. You might be able to just say >> that we delay the expansion of `lambda' bodies 'as long as possible', >> but that that point it seems like we're not gaining very much. >> >> [1] >> http://docs.plt-scheme.org/reference/stxtrans.html#(def._((quote._~23~25kernel)._local-expand)) >> [2] http://www.ccs.neu.edu/scheme/pubs/scheme2007-ctf.pdf , Sections 3.4 >> and 4 > > I'm afraid I don't have time to fully understand the way-too-many forms > of PLT macros, so I can't really tell if local-expand would be a > problem. Off-hand, I don't understand why: If the expanding a lambda > body is deferred, and the lambda body contains a local-expand, then the > local-expand gets deferred.
I was just pointing out that with `local-expand', it's not possible to ensure that the expansion of macro bodies is not forced earlier than it would otherwise be. Upon further reflection, I'd say that I'd rather have the the early error detection of full expansion of each REPL-entered form, and the ability to forward-refer to macros in programs, than an exact correspondence between the semantics of R6RS-style top-level programs and forms entered sequentially at the REPL. -- sam th [email protected] _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
