Re: FWD:Re: refactoring

David Abrahams wrote:
> Joel de Guzman <[email protected]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Joel de Guzman <[email protected]> writes:
>>>
>>>
>>>>WRT templates and the C++ type system, my current thinking is that
>>>>I need an embedded runtime interpreter specifically geared to
>>>>handling the C++ meta template language. It would be a minimalist
>>>>FP language similar to scheme/lisp. 
>>>
>>>Sorry, I can't picture where you'd need this, or what you'd use it
>>>for.  More detail, please?
>>
>>Hmmm... Ok, I'll give it a shot:
>>
>>The C++ meta template language is a complete FP language that is
>>executed (interpreted) at compile time one way or another. The
>>advent of modern c++ and especially template meta programming
>>makes me think that an adhoc solution to "interpreting" this
>>language is no longer adequate. IMO, an elegant way to address
>>this is to actually formalize the compile time interpreter.
> 
> 
> Ah, yes.  I've had a similar thought.  Especially because you could
> then -- theoretically at least -- compile templates down to object
> code that does the instantiation work, for faster compilations.  But
> still I have to wonder if any speed can really be gained; most of the
> instantiation steps are already compiled into the compiler's object
> code.

The advantage of formalizing the parse/compile time interpreter
is not only in terms of speed, which is questionable, I agree.
The big advantage, I think, is in extensibility, tweak-ability
and expressivity. I'm sure we all know the benefits of having
a domain specific language focused at the task at hand. It's
a lot easier to reason with, analyze and visualize if a complex
task is modeled as a formalized language rather than hard coding
the behavior and mechanisms involved.

>>A template class can be modeled like a function with multiple
>>arguments (template parameters) and multiple returns (typedefs).
> 
> 
> Well, except that there can be a lot more in the class than just
> types.  And even the types don't have to be typedefs.  This applies
> even if the class template is only used as a metafunction, which of
> course isn't guaranteed.

Sure. Those too, should be modeled by the interpreter. If we
wish to think in terms of pure FP, perhaps closures might
be a nice solution. Then, the added info will be the environment
surrounding the function.

>>Types are values in the POV of the compile time interpreter.
> 
> 
> Also in the POV of a compiler ;-)

It is a fact that in C++, the line between the parser (front end)
and the compiler (backend) blurs. You need some smarts of the compiler
to reliably parse C++. The sizeof comes to mind, for example.
By "compiler", I mean the backend code generator.

>>The notion of a "metafunction" will be just an ordinary function
>>in the viewpoint of the compile time interpreter. Partial/full
>>specializations will be cased and pattern matched like in haskell
>>(http://www.haskell.org/tutorial/patterns.html).
> 
> 
> The compiler already has to do that.

And so should the parser, if you want it to do such tasks
as extracting the function signatures, providing meaningful
error reports, etc.

>>Imagine, for example, how TMP code such as MPL and Boost libraries
>>in general, will benefit from actually having it interpreted by
>>the formalized compile time interpreter. 
> 
> 
> If you want to get conformant C++ behavior, your formalized
> compile-time interpreter will have to be semantically equivalent to a
> C++ compiler, so I'm not sure I see the benefit.
> 
> 
>>We can provide optimized
>>intrinsics specific to, say, MPL and type_traits, that would
>>be "compiled" instead of "interpreted" in the POV of the meta
>>domain. 
> 
> 
> Okay, that we could do, if there was a way to give the compiler
> special knowledge of particular metafunctions.  So you're thinking of
> something like:
> 
>   #ifndef BOOST_META_COMPILER_EXTENSION
> 
>   // normal mpl::if_ implementation here
> 
>   #else
> 
>   template <class C, class T, class F>
>   struct if_ : 
>      (cond C T F)  // Code for your interpreter.
>   {};
> 
>   #endif
> 
> 
>>Such would give dramatic improvements in parse/compile
>>time.
> 
> 
> Yes, it might!  It seems to me that you could bypass many of the usual
> costs of template instantiation.
> 
> I think this is a really interesting alternative to David
> Vandevoorde's metacode approach.  One of my big concerns about
> metacode is that it has not yet been shown to offer improved solutions
> in the area of some of the major applications of TMP.  For example,
> David and I looked at how to implement lambda in metacode, and didn't
> get far.

Yes. If the formalized compile time interpreter is simple enough
like the language Scheme, we can easily have a compile time
meta-compiler-compiler that compiles directly to compiler object
code. Then, TMP infrastructure libraries such as MPL can start
doing meta-meta-programming :-)

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net