Proto for Boost mailing list page: Re: [proto] talking proto

Subject: Re: [proto] talking proto
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-07-18 17:56:29

On Sun, Jul 18, 2010 at 11:55 AM, joel falcou <joel.falcou_at_[hidden]> wrote:
>
>> I'm pretty sure I understand this. I briefly looked into OCaml, so this
>> is familiar. Are the alternates tried in order or is there some notion
>> of "best match" like with template specialzations?
>>
>
> There is a funky algorithm to do this quite fast
>>>
>>> If you "forgot" a case that make the function not working, ML will
>>> complain and in some case give you the missing case.
>>>
>>
>> How in the world is that computable in general? Is match...with
>> restricted to list-like thingies?
>>
>
> Nope. The typer "tries" to help you by giving you an example of missing
> stuff.
> If it can't he just say "missing match cases dude"
>
>> Cool. So you're using this to validate your semantic actions?
>>
>
> to debug them in a friendly environment ;)
>>>
>>> Now, look at this again and replace let with template<class T> struct
>>> len and match by template specialization. Bingo, you got the exact same
>>> function turned into a meta-function.
>>>
>>
>> I object! The len function computes the length of a *runtime* list.
>> Obviously with template specializations we're no longer dealing with
>> runtime data structures. I don't see how to the two relate.
>>
>
> Runtime values in ML <-> Compile-time value in C++ TMP
> A function in ML operatirng on list of values becomes a meta-funtion in C++
> operating on types list.
> Both languages beign pure and functionnal helps the transition.
>
> Just make a ML compound type like
>
>
> type Type = f of Float | d of Double | i of Integer;
>
> and let's have a polymorphic list of Type.
>
> let l = len [ Float; Flaot; Double ];
>
> see where we're going ?
>
>> Good luck!
>>
>
> The stuff is pretty much here. Need some sla... students to do the work ;)
>>
>> In theory it should be possible to add a theorem prover to proto to
>> validate semantic actions, right? Not that C++ TMP is necessarily the
>> best tool for this.
>>
>
> I think it's better as an outside tools. However, a DSL for HOARE logic
> injection in C++ is another beast ;)

Haskall is also something good to model, it is kind of like the above,
and like the above you can think of both as like a meta-programming
language that is mostly executed at compile-time to generate very
efficient runtime code.  I do that with the toy language I created
(list-like syntax and power, but no shared state and some other
changes), it is not executed procedurally, but is rather executed at
compile-time, which then generates LLVM code based on what it
generated, which is then optimized by LLVM and JIT'ed.  Lisp style
macro's make that so easy to do as well.

You might also look at D, its template support is vastly more powerful
then C++'s while retaining the same feel (although with a *lot* of
things to make it not as verbose), the interesting thing is that D's
templates support strings, and especially interesting is that the D's
template syntax is a unique construct, it could fit into C++ as well.
I always kind of thought of playing around with that, using Clang to
create a C++D language or so that would still be pure C++, but with
some D constructs that would benefit it, like D's template system
side-by-side with C++'s template system.  And the one feature that
would be nice to bring to C++ that I have not mentioned yet, are
mixins[1].  The mixin command can take any arbitrary compile-time
string (whether a plain string, a string generated from a const
readnone function that is 'run' at compile-time, or returned by a
template) and it drops it in-place as a string to be compiled by the
compiler, so these do the same thing:

struct Foo { int bar; }

// and:

mixin("struct Foo { int bar; }");

// and as taken from the mixin page example:

template GenStruct(char[] Name, char[] M1)
{
    // ~ is the array concatenation operator in D, and strings are just arrays
    const char[] GenStruct = "struct " ~ Name ~ "{ int " ~ M1 ~ "; }";
}
mixin(GenStruct!("Foo", "bar")); // when a variable name in a template
declaration has the same name as the template declaration itself, then
you do not need to ::name it, it is implicit, but the above could have
been this too:
mixin(GenStruct!("Foo", "bar")::GenStruct);

As you can see, the template syntax of D is compatible with C++
without interfering with anything, instead of templateName<param> it
uses templateName!(param), so they could live side-by-side.

That would be such a fascinating idea to carry out, C++ needs to be
extended with such new constructs, it needs full compile-time
reflection (it is so close to it too, but it just does not pull it
off), etc...

[1] http://www.digitalmars.com/d/2.0/mixin.html