On Wed, May 4, 2011 at 9:37 PM, Jim Rees <[email protected]> wrote: > >> 1. (one I mentioned before) Is it just me who thinks that it is a bad >> idea to have same quasiquote forms expand correctly in one context and >> fail in another? > > You're referring to the fact that "(unquote 1 2)" is sometimes legal or not, > depending on what's surrounding it, right? > I might agree if I thought UNQUOTE and UNQUOTE-SPLICING were actual > syntactic forms, like QUOTE or DEFINE-SYNTAX. But really, they're just > literal identifiers which QUASIQUOTE looks for when it walks its input form > (like ELSE and => for COND).
I think the whole job of dealing with unquote/unquote-splicing could still be contained in the implementation of the quasiquote form only provided that: - quasiquote expands to a list, not a single form - a form containing quasiquote "splices" splices the resulting list into itself. The second step might be tricky and that's (I guess) what Peter was referring to as a "huge change". This certainly is a substantial change but it results in both cleaner behavior of quasiquote and more convenient and powerful macros in general. I'll go ahead and try to implement it just to see how it would look like in practice. It is backward compatible with both R5RS and R6RS anyway. >> 2a. As a performance optimization. Imagine that "macro-apply" expands >> to some complex expression. It is usually cheaper to evaluate: >> (some-procedure (macro-apply some-contents)) >> than: >> (some-procedure (macro-apply-car some-contents) (macro-apply-cadr >> some-contents) (macro-apply-caddr some-contents)) > > Interesting idea. Note that if you merely move the name SOME-PROCEDURE > into the argument list of MACRO-APPLY, then the macro can return just one > form and achieve the same effect. Sure I could, probably even with an identical result. The difference is that 'macro-apply' would likely have to be more specialized (that is, have some knowledge of 'some-procedure'), adding it would require deeper changes to the caller side program. Also, doing it the way I proposed could simply result in an easier or more convenient abstraction. Andrzej _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
