Lambda the Ultimate

"Lazy passing of unevaluated expressions" is certainly similar to macros, and the connection with partial evaluation is good. The only real hole in that picture is that naive passing of unevaluated expressions loses the original expression context, a shortcoming that macro systems have worked very hard to overcome. So the typical modern macro system (Scheme's syntax-case, for example) provides a much richer notion of the contexts of both macro definition and macro expansion. Since modeling this context typically relies on heavy interaction with compile-time data structures or semantic structures (symbol tables, binding environments, etc.) modeling the semantics via run-time passing of unevaluated code is more problematic.

But the idea of phased computation is really powerful, including macro expansion on one side and staged evaluation (dynamic eval) on the other and a permeable boundary between static and dynamic phases (perhaps based on partial evaluation). This is IMHO something of a holy grail.

You might enjoy Macroexpansion Reflective Tower, if you haven't already seen it.

The only real hole in that picture is that naive passing of unevaluated expressions loses the original expression context, a shortcoming that macro systems have worked very hard to overcome.

I thought this would probably be the main difference. As I alluded to in my post, you have to play tricks with [uplevel] in Tcl which is not a satisfactory experience. I've been meaning to really get to grips with Scheme as a day-to-day language for a while now, so that will give me a chance to get a handle on using a macro system and how it compares to other approaches.

Thanks for the link, I hadn't come across that particular paper before.

Oh man returning of lambda forms from functions in emacs lisp. That is painful, because there are only dynamic environments, and so no syntactic closure. To fake syntactic closure, instead of using (lambda (x) x) (which actually evaluates to itself when not being applied), you have to use quasiquotation.

in my little understanding ad knowledge, I think that one of the best approaches to passing unevaluated expressions to functions are Scala's automatic closures, which allow you to build new control structures avoiding the need for the caller to explicitly state that an expression must be evaluated lazily

that that code looks alot more eqvivalent to the lisp code:

(define (when-ready body)
  (wait-until-ready time-out)
  (if (not (ready?))
      (eval body)))

(when-ready
  '((display "I am glad this is finally ready!")
    (newline)
    (do-something)))

than the code in the article.

Although I don't see the need for the (if (not (ready?)) ...) condition. But the point I was making was that doing things this way is just as easy as with macros. In fact, it's slightly less code and to my eyes is easier to read. The problem, as pointed out, was scope. The Tcl version evaluates its script in the global scope. I could have made it evaluate in the dynamic enclosing scope by using [uplevel 1 ..]. That is usually the Right Thing, at least for Tcl.

Going further, in the same blog post as the topic of this discussion, there is a link to this post describing further uses of macros where "[p]rocedures would not work...". Well, as far as I can see procedures would work for both of those examples. I'm pretty certain both could be easily written in Tcl (it would be easier if I could understand the lisp code that implements the vector example, but it looks like Perl to me). The only big issue is getting the scope right. Tcl solves this with uplevel, which seems a much simpler solution than a full-blown macro system.

Just thinking that it might be good to point out that you can do it that way in lisp to. But as you pointed out, you get problem with scope.

And by the way you probably can do a macro in lisp that let you write macros in the Tcl syle whithout having any scope problems.

So I guess the possibility for separation of evaluation order from code proper is minimal (it is not an aspect, or maybe aspects are not really separatable, too... :-) ).

Well, to each his own. For me, strictness is so intuitive that I can only understand lazy code by either pretending it's strict (which breaks down quite soon) or by mentally wrapping everything in sight with a thunk (which makes the code insanely complicated).

But I don't understand what this has to do with order of evaluation. Lisp prescribes left-to-right order for function calls, but Scheme explicitly states that no ordering can be assumed (the semantics even have a randomizer to prevent you from reasoning about evaluation order), though both are explicitly strict.

I agree that sometimes it'd be nice to tell a macro from a function call right off, but if you want that, use a naming convention.

You have to examine enough context to know whether the form is a standard function call or a macro. Haskell and Smalltalk seem more elegant for not having this problem. (And in Smalltalk, it even eliminates syntax for things like "if".)

Of course, lazy evaluation obviates the need for macros in many cases, but they're certainly still useful, and if you have them, you still have the same problem...

Sounds amusing. I can imagine how this can happen. Still it would be amusing to see the reaction the developers had at the time. Is this reaction recorded in writing somewhere, I wonder?

Not the editor, but the Scheme front-end (or top-end), which is itself very interesting, I think. You specify which formal parameters are to be procedures (if you want, it's not a requirement), and matching actual parameters are automatically wrapped in thunks, just as in Algol 60.