This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]