On Wed, May 4, 2011 at 9:37 PM, Jim Rees <jimreesma@gmail.com> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports