On 28 Aug 2001 05:44:57 +0900, Avi Bryant wrote: > On Tue, 28 Aug 2001, Sean Middleditch wrote: > > > But should this eval() be built into the language itself as a core > > component? I can where, perhaps if one wished to play with full > > meta-programming, it would be necessary, but neither do I see a need for > > meta programming outside of the academic field. or are there some examples > > to prove me wrong? Again, I'd rather be proven wrong and corrected now than > > just be wrong for a long time to come. ^,^ > > This article has already been mentioned once in this thread, but: > http://www.paulgraham.com/lib/paulgraham/sec.txt > Wow. I like the points he makes. I've actually studied LISP a lot, and though I've never really enjoyed working with it (as the author of the article says, I'm much like the "Blub" programmer, although in my case "Blub" is C/C++), I've always loved its power and flexibility. As my language has no compiler yet, all executable code is generated in C (i.e. directly building the parse trees) and reminds me a lot of LISP. To me, the job of any compiler for my language would be to build these LISP-like trees, then optimize the Hell out of them, and put them to disk or feed them to the byte-code interpreter. I would suppose that any language developed for my language backend could very well give the language access to the byte-code trees. I honestly think that during my design of the byte-code interpreter for my language, feature-wise I've been heavily inspired by mainly LISP and Ruby. ^,^ > I think he says something like 25% of the code is macros (which > definitely counts as metaprogramming), and this is in a highly commercial > setting. > > Now, metaprogramming doesn't have to be run-time, or require eval - > something like AspectJ (ok, those guys don't like me to call it > metaprogramming, but...) works as a preprocessor on Java code, which isn't > really that different from how Lisp works, since macros are expanded at > (roughly) compile-time anyway. > Understood. > As for whether there's a "need" for it, there are absolutely some problems > that become much, much easier at the meta-level (Ruby's attr_accessor > method is a very simple case in point; something like the GOODS object > database is a more complex one). "Need"? Insert standard > Turing-completeness disclaimer here. > Easier, yes. Definitely easier. But all the newer languages that I've seen, such as Ruby, is just a C interpreter. The question is how much flexibility do you need for your task, and thus just what does that C backend need to do. Many applications, if designed intelligently, don't need all that much more power than C itself offers. I've yet to run into a situation where I would need more flexibility, although I'm quickly seeing that quite a few other people have found such things. Sometimes it's incredably depressing knowing how little you know. ^,^ > > C/C++ is my most familiar language actually. I haven't looked into Algol at > > all, although I'm slightly familiar with COBOL. I've studied newer > > languages a lot more though, especially lately. > > By "Algol-spawn" he was referring to the loose family of > C/Java/etc, usually in contrast to Lisp. > Oh. ::sigh:: another language added to the growing stack of languages I need/want to learn now. Was Algol that highly used of a language? I've not heard much about it. > > In any event, I find that rarely is there anything I need to do in C/C++ > > that isn't possible. Sometimes just a bit hard to do. ^,^ > > Sure. If it really comes down to it, you can just use C to write a Lisp > interpreter... or Ruby ;-). > Which is more or less what I'm doing. ^,^ Thanks for tips, Sean Etc.