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

Subject: Re: [proto] talking proto
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-07-20 01:08:38

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
> On 7/18/2010 5:56 PM, OvermindDL1 wrote:
>> 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.
>
> Sounds intriguing. I'd have to get my hands in it to really grok that,
> though.

I hope to release it someday, whenever I get time to make it
releasable, right now it is just a toy project, but it works.

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> Lisp style
>> macro's make that so easy to do as well.
>
> So I'm told. ;-)

Even that defmacro link I sent you above is only half the description.
 Lisp has two types of macro's, there is the normal macro, that the
article described, it mutates the parsed stream into a different
parsed stream, and the other kind is the read-macro, which mutates the
character stream into a parsed stream, you could write a C++ parser,
or Python parser, or anything as a read-macro and have it compile to
lisp, the pure power is unbounded as I am sure you can imagine.

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> You might also look at D, its template support is vastly more powerful
>> then C++'s while retaining the same feel
> <snip>
>
> Ha, yes I know quite a bit about D. Little known fact: I regularly
> attended the weekly BS sessions with Walter Bright, Andrei Alexandrescu
> and others to design D2 (although I mostly just sat and listened).

Heh, nice, I always looked at it as an oddity, it has such amazing
promise, but there is so much splitting in its community, plus the
fact it is not backwards compatible (although probably a good thing in
its design) so it cannot compile the huge swath of C++ code out there
have kept me from actually using it.

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> I always kind of thought of playing around with that, using Clang to
>> create a C++D language
>
> Dear god, why? If you prefer D, then by all means use it! :-)

Heh, the above reason, D cannot compile C++, and near all my stuff is
in C++.  :)

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> And the one feature that
>> would be nice to bring to C++ that I have not mentioned yet, are
>> mixins[1].
> <snip>
>
> Grumble. Mixins are about as horrible as the C preprocessor. No, more so
> because they're more powerful, and equally dangerous. If it's your goal
> to manipulate /code/, why manipulate /strings/? Isn't the Lisp way
> better? I'd rather manipulate syntax trees than hack together some
> Frankenstein monster by building a string at compile time (!!!) and
> barfing it into some arbitrary context. Sorry, did that make me sound
> opinionated?
>
> I get the impression that even Walter and Andrei have misgivings about
> mixins.

Well they are a hair better in that they have to be syntactically
complete, no open parens or so.  Yes, the Lisp way is better, but
until the C++ compiler can interpret/jit C++ during compile to alter
the AST, not easy to do then...  Until then, those mixins are the
closest to lisp-power that we have (although still not anywhere near
close).

Reminds me of Greenspun's Tenth Rule:
Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of
Common Lisp

Not altogether inaccurate either and can be applied to almost any
language nowadays, always trying to attain Lisp's power...

On Mon, Jul 19, 2010 at 9:04 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> 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
>
> Ah, here I agree. But without the ability to traverse and manipulate the
> AST at compile time, reflection can only get you so far.

Well, why not go all the way, as per the defmacro article, why not
something like this built into CLang:

__compiletime
{
  #include <iostream>

  __attribute("macro=square")
  void alter_square(AST *ast, whatever else)
  {
    // Alter the ast which includes a call to a square function call
to inline it
    // Converts something like "int i = square(42);" into "const int
uniquename=42;int i = uniquename*uniquename;"
    //  or any generic "type square(type val)" to "const type
uniquename=val;uniquename*uniquename" or whatever.
  }

  __attribute("macro=example")
  void alter_example(AST *ast, whatever else)
  {
    // Could do something like read a database configuration and build
    // up whatever you need, or how about just read an integer from
    // the input stream at compile time to multiply to.
    int i;
    i << std::cin;
    // change "example(int val)" into "val*"+lexical_cast<std::string>(i)
  }

  // Could have lots of other attributes for operating on various things,
  // from function type signature changes to operating on the character
  // stream itself to generate a parse tree.  The AST above would, for
  // example by CLang's internal AST with all its power.
}

int main()
{
  return example(square(42));
}

Certainly there is a better syntax, but CLang could be extended to run
some compiletime section at compiletime to let it hook into the AST at
certain points or something, perhaps some kind of dom-style matching
statement too, or just start parsing the character stream itself at
certain points or so.  With this you could literally have Lisp-style
power, just, obviously, not as easily succinct as Lisp does it, but
still fully capable.  The compiletime C++ could be garbage collected
for ease of use or whatever else too.  Perhaps also let functions be
marked that they can be run program-side as well as compiletime-side.

Meh, mostly a bit of brain-dump...