Update: Stephen Pair gives a parse tree example in the comments.
Don Box has another post up showing how to create lambdas in C#. The syntax for all that looks pretty baroque to me. In any event, Don asked in the comments to my last post on this for the Smalltalk equivalent. I'm not going to generate a list and compile that, as he does with Scheme and C# - in Smalltalk, we'd have a string, and just evaluate that at runtime. Same idea, just not the same machinery. So the way I'd approach his problem in Smalltalk:
" Creates the function that adds one to the input value " func1 := [:a | a + 1]. " String for the same function " func2String := '[:a | a + 1]'. " Print that to the Transcript window " Transcript show: func2String. "This will raise a MessageNotUnderstood: #value " func2String value: 4 " Have the compiler evaluate the string, which gives us the function " func2 := Compiler evaluate: func2String. "Now execute that, which gives us the desired answer of 5 " func2 value: 4
If you were really hung up on creating a List, you could do that with MessageSend objects, and then hack the compiler a bit to get it to deal with lists instead of strings. That's not how Smalltalk works though (it's kind of cool that you could make it work that way - I've had University students tell me about projects to implement that in Smalltalk). The Compiler is just another object that you can subclass and/or extend - the IDL compiler for CORBA and the DLLCC parser for our foreign language interface are both implemented that way. In general, you can tell any class which compiler to use (allowing you to easily create domain specific languages).
The bottom line is, creating code whose execution is deferred until later is easy in Smalltalk - and is still easy if you want to create that code on the fly by generating the code and then compiling it at runtime.