From: Spiros Bousbouras on
On Mon, 30 Nov 2009 11:38:38 +0100
Pascal Costanza <pc(a)p-cos.net> wrote:
> Spiros Bousbouras wrote:
> > This is a sequel to "Remembering information during compilation"
> > < http://groups.google.co.uk/group/comp.lang.lisp/browse_thread/thread/460e44871936c99c >
> >
> > For this we want 2 macros:
> >
> > jumpbody (&body body)
> >
> > Creates a tagbody and puts body inside the tagbody.
> >
> > jump (&optional depth)
> >
> > depth must be a positive integer known at compile time ; default is 1.
> > jump transfers control through the use of a go to the beginning of the
> > depth-th lexically enclosing jumpbody where "beginning" means before
> > the first form of body of the corresponding jumpbody. So for depth = 1
> > control is transferred to the beginning of the innermost jumpbody , for
> > depth = 2 to the next one and so forth. If there are less than depth
> > enclosing jumpbodies an error is signalled.
> >
> >
> > First question: Is this a complete specification i.e. is it enough to
> > decide what should happen in each situation the above macros are used as
> > part of otherwise conforming code ?
>
> Do you want this to be hygienic?
>
> So for example, given the following macro:
>
> (defmacro user-space-macro (wrapper)
> `(jumpbody
> ,(wrapper (jump 1))))
>
> (user-space-macro jumpbody)
>
> Where do you want this to jump?

I hadn't thought of this possibility and I guess the point is that
wrapper make create another jumpbody around (jump 1).

> More importantly: How can you ensure that it jumps to the place you
> actually want it to jump?

I think you could if you wrote a custom made code walker/
macroexpand-all but I'm not that ambitious. So I guess I need to add
some things to my specification. Let me try again:


Macro jumpbody (&body body)

Creates a tagbody and puts body inside the tagbody.

Macro jump (&optional depth)

depth must be a positive integer known at compile time ; default is 1.
jump transfers control through the use of a go to the beginning of the
depth-th lexically enclosing jumpbody where "beginning" means right
before the first form of body of the corresponding jumpbody. So for
depth = 1 control is transferred to the beginning of the innermost
jumpbody , for depth = 2 to the next one and so forth. If there are
less than depth enclosing jumpbodies an error is signalled.

Lexically enclosing jumpbodies are not just those explicitly created by
the programmer but also those which may appear after expansion of
macros which occur between a jumpbody and a subsequent jump.


Is this an unambiguous specification ?

--
Any sufficiently advanced bug is indistinguishable from a feature.
Rich Kulawiec
From: Thomas A. Russ on
Spiros Bousbouras <spibou(a)gmail.com> writes:

> Macro jumpbody (&body body)
>
> Creates a tagbody and puts body inside the tagbody.
>
> Macro jump (&optional depth)
>
> depth must be a positive integer known at compile time ; default is 1.
> jump transfers control through the use of a go to the beginning of the
> depth-th lexically enclosing jumpbody where "beginning" means right
> before the first form of body of the corresponding jumpbody. So for
> depth = 1 control is transferred to the beginning of the innermost
> jumpbody , for depth = 2 to the next one and so forth. If there are
> less than depth enclosing jumpbodies an error is signalled.
>
> Lexically enclosing jumpbodies are not just those explicitly created by
> the programmer but also those which may appear after expansion of
> macros which occur between a jumpbody and a subsequent jump.
>
>
> Is this an unambiguous specification ?

It is fairly clear.

Now, it doesn't seem to be to be practically useful, especially with the
possibliity of having macros that you haven't even written insert
additional "catch points" for your jumps. It would mean that when you
include the (jump 3) macro in your own code, you really don't have any
idea where your control flow will end up. Someone else's macro may have
inserted an additional level that you would need to jump to.

As someone else pointed out, using the named blocks and return-from
would be a much more predictable and simpler to understand control
construct.

--
Thomas A. Russ, USC/Information Sciences Institute