>>38
Very nice, but (in this case) that's not the same as run-time code generation (which is what was being discussed). Indeed, no new programs are created at runtime by the snippet you displayed; everything is created statically, when your batch compiler (GHC) first batch processes your program.
Since you are a Haskell programmer maybe studying how to do run time code generation in your language, and contrasting it to that example of plain old static code generation you showed me will help you understand the difference?
http://hub.darcs.net/stepcut/plugins
Today, a "lambda" or "closure" feature (or whatever your language calls it) in a language is hardly special. Many languages feature them today. Here are a few examples of something similar to what you showed me in Haskell in other languages off the top of my head:
;; In Common Lisp
(progn
(let (silly)
(setf silly (lambda (x) (* x x)))
(funcall silly 4)))
"In Smalltalk"
[|silly|
silly := [:x | x * x].
silly value: 4.] value.
// In C++
auto silly = [](int i) { return i * i; };
int result = silly(i);
None of this is the same as run-time code generation. To contrast:
;; In Common Lisp.
(progn
(let (silly)
(setf silly (compile nil (read-from-string "(lambda (x) (* x x))")))
(funcall silly 4)))
"In Smalltalk"
[|silly|
silly := Compiler evaluate: '[:x | x * x]'.
silly value: 4.] value.
// In C++
// Just kidding C and C++ provide pretty much only pointers
// for metaprogramming hence this whole discussion. Please
// read my earlier post on how to laboriously do run-time
// code generation in C.
Now notice the string in both examples could have come from some file, network, user input, or any other thing not knowable apriori, at compile time.
So hopefuly this sort of gives you some idea on what run-time code generation is and the topics discussed earlier.