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.