This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: More tagbody
- From: "Are Meisfjord" <are at meisfjord dot com>
- To: per at bothner dot com
- Cc: kawa at sources dot redhat dot com
- Date: Thu, 3 Apr 2003 10:30:17 +0200
- Subject: Re: More tagbody
>From: per at bothner dot com
>>Are Meisfjord wrote:
>>> (define (test)
>>> (let ((val '()))
>>> (try-catch
>>> (letrec ((start (lambda ()
>>> (set! val 1)
>>> (point-a)
>>> (throw (make <java.lang.RuntimeException>))
>>> (set! val (+ val 16))
>>> (point-c)))
>>
>>This doesn't make sense - why the set! and point-c call after
>>the throw?
I was trying to mimic the (not yet written) tagbody macro. This is
the original example from Franz' documentation:
(let (val)
(tagbody
(setq val 1)
(go point-a)
(incf val 16)
point-c
(incf val 04)
(go point-b)
(incf val 32)
point-a
(incf val 02)
(go point-c)
(incf val 64)
point-b
(incf val 08))
val)
This is how I am planning to implement the tagbody macro:
The body of the tagbody statement is divided into blocks by the tags.
Each block is transformed into a lambda expression. Each lambda has
to end with a call to the next block, which will be invoked during
runtime if no go statements are reached.
Each go statement is transformed into a sequence of two function
calls: first a call to the lambda corresponding to the specified tag,
then a call to throw to stop execution when the lambda returns.
The set! is there simply because it is in the original example from
Franz (incf val 16). I don't know why they put it in there as it will
never be reached during execution, as you noticed.
I guess I should have explained this in the original mail as I can
see now that it looks quite strange. And of course, feel free to
comment if you have further questions or suggestions for improvements.
>>> As you can see I get away with at most one exception thrown per
>>> tagbody (any suggestions on how to get rid of it?)
>>
>>I suspect you'll have to do some Java coding. Basically, you
>>want to have the code expand to a BlockExp/ExitExp, possibly
>>after optimization. The easiest might be to implement
>>the CommonLisp block and return-from forms, which map
>>pretty directly into BlockExp and ExitExp. If there is
>>some similar form in some Scheme implementation, that
>>might be better.
I will try the approach I described above first and see how it
affects performance. But again, thanks for the advice!
Regards,
Are