Hacker News new | ask | show | jobs
by Kamq 835 days ago
Hmm, ok, I think I might get what you're saying, it's not exactly what I thought you were getting at originally. Although I'm not quite following still. I did bring up hooking into the reader, but that was for something more than just the basic TCO with macros. I'm reasonably sure that what I was talking about can be done with normal macros themselves.

Just to check my understanding:

So, going back to your example, we have 3 functions f, g, and h. These will be re-written as one big function with gotos and three helper functions that call into the right point of that function.

So, is your objection to this that the other functions are re-written, or that a new function is defined in the namespace you happen to be in?

To elaborate further, let's say f, g, and h are defined in order. When f and g are compiled, nothing happens, but when h is compiled, noting that f and g are already defined, h is compiled into something like:

    (defun h (x)
      (flet ((fgh-loop (start-at x)
               (tagbody
                 (case start-at
                       ((f) (go f))
                       ((g) (go g))
                       ((h) (go h)))
                   f (a x) (go g)
                   g (b x) (go h)
                   h (c x) (go f))))
      (fgh-loop 'h x)))
Obtaining the definitions for f and g by examining the environment and copying them over. That should be alright, in your opinion, right?

There's not as much benefit, as f and g don't get the optimization, but in exchange we don't get spooky action at a distance.

How about if we used a macro to define functions instead of the traditional defun? Each one registering the function as willing to be re-written when everything they depend on is defined. That should give the user of the code a warning that these functions are likely to be re-written. Functions that aren't defined using this macro aren't re-written, but don't gain the benefit.