On Tue, Mar 04, 2014 at 10:54:30PM -0800, David Mertz wrote:
As *I* am thinking of it, a "thunk" is really just like a C macro. Not even really like a Lisp macro. So it's not like a function in that it doesn't define a scope, doesn't have a call stack, etc. It's just "pretend I typed these other literal symbols here." Maybe I should stop calling the idea a thunk, and just call it a macro.
I'm intrigued by this suggestion. I think that what I'm really after is two things: lazy evaluation, and dynamic scoping. I think a macro would give us both.
But hasn't Guido said No Macros at some point?
However, I'm pulled in several directions here. On the one hand, if it really is essentially the same thing as a code object, I'm not convinced we actually need syntax for it. That is, what's really the point of having
a = $(expr) # or `expr`, or `(expr), or c"expr"
If it's simply a slightly shorter way of spelling:
a = compile(expr, "<string>", "eval")
You can't write it like that. You have to wrap the expression is quotes and turn it into a string:
a = compile("expr", "<string>", "eval")
which means you lose syntax highlighting. Perhaps the ability to get syntax highlighting is not sufficient to justify this idea.
Another disadvantage: the ever-present temptation to pass a user-generated string to compile:
a = compile(template % some_string, "<string>", "eval")
If some_string came from an untrusted source, you are now the proud owner of a brand new code injection vulnerability. But with syntax, you cannot generate a thunk/macro except from code you write yourself. It's still code written by you, it's just that evaluation is delayed.