[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: Re: COMPILER-LET
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Tue, 27 Sep 88 13:19:20 MDT
- Cc: Sandra J Loosemore <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: email@example.com, Tue, 27 Sep 88 10:37:09 -0700
> Date: Tue, 27 Sep 88 10:37:09 -0700
> From: firstname.lastname@example.org
> if you wanted to COMPILER-LET several
> variables that were consumed by the same macro, the combinatorics of your
> solution would be bad news.
I don't think so. The problem comes in when you have several variables
that are used by several macros.
> Further, in your solution, the scope is wrong.
Could you please explain why you think the scoping is "wrong"?
> In any event, I hope that COMPILER-LET remains in the language. I have found it
> an easy and natural construct to use for implementing various language
I would like to see some actual examples of how you've been using it in
real code. All the ones we've dealt with so far have been artificially
> In addition, it seems that it should be trivial to make EVALed
> forms enjoy the same semantics that the compiler proffers.
Actually not. As we've already discussed on the cl-compiler mailing
list, it would require all implementations to have their interpreters
do a code-walking prepass to perform macroexpansion, instead of
allowing macroexpansion to be performed in parallel with evaluation.
Some implementations do work that way already, but the change for the
rest would hardly be "trivial".