From: David B. Held (dheld_at_[hidden])
Date: 2003-10-26 01:32:49
"Joel de Guzman" <joel_at_[hidden]> wrote in message
> It would be very difficult to debug because of the side-effects.
Could you give a concrete example?
> I'm quite happy with the *functional* nature of the template
> processor, thank you. An imperative template processor will
> open up a can of worms. I don't even want to start imagining
> a step debugger at compile time! Yaiks! No, please don't!
I'm not talking about a template processor. I'm talking about
a language which supports multiple levels of abstraction
seamlessly. I'm talking about what you might immodestly
call a "5GL". ;> And don't just imagine a compile-time debugger.
Imagine a meta-compile-time debugger, a meta-meta-compile-
time debugger, etc. Imagine a language in which the source
code and compiler form the execution environment of the
meta-compiler. Imagine what possibilities for reflection and
code generation are possible. Yes, it's enough to stretch one's
mind quite to goo. But if we had real meta-exceptions, instead
of mere compiler diagnostics, and a real meta-i/o facility, then
perhaps the idea of a meta-debugger is not so scary or far-
> IMVHO, there's nothing wrong with the functional nature of
> the template processor.
No, there's not. It has served us well, and will continue to do
> Why make it imperative when everyone knows that
> functional is better? C'mon guys! This is a step backwards!
I disagree. This time, given the choice between A and B, I
choose 'yes'. ;) I would want this hypothetical meta-language
to fully support FP with native lambda, closures, etc. (maybe
even monads ;). And not just at run-time, either. Think meta-
OOP...building up types and meta-types as if they were values.
The person who should be having nightmares is not the
programmer, but the compiler implementor!
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk