May 11

Finally, yesterday was the day! Joel and I presented the current status of our work related to the ‘Writing a Compiler’ effort. We submitted this talk to BoostCon 2010 and got accepted back in January. Having to present at BoostCon just put a nice pressure onto us to get moving and to start working on the project. I don’t want to go into any detail about the presentation itself. This will be done in future articles to be published after BoostCon. I just wanted to provide a link to the slides for those interested in having a look. Ok, here we go: A Framework for RAD Spirit, grab it while it’s hot!

14 Responses to “A Framework for RAD Spirit”

  1. Gustavo says:

    Would it be possible to have the full source code of the example presented on the slides?

    • Hartmut Kaiser says:

      All of the code is available from Boost SVN trunk (in $BOOST_ROOT/libs/spirit/example/scheme).

      Regards Hartmut

      • Shawkat says:

        Which version of boost does this compile with? I have not been able to compile it with version 1.50.0. I have not use jam; just simple gcc; something like
        gcc -I……./boost/1.50.include -I…./scheme -c scheme_test3.cpp

        There are some obvious problems, such as boost:;spirit::scope is not found.

        Can you please help ? Thank you.

    • Joel de Guzman says:

      Yes, after I clean it up some more.

      • Larry Evans says:

        The in-source comments in utree_detail1.hpp around line 92 (just before
        ‘struct fast_string’) mention alignment_of(list); however, there’s no
        in-source comments about why alignment_of(list) was used.

        It might demystify the code somewhat if some in-source comments were
        added explaining why list was chosen.

  2. Wish I could have been there – the slides look great but I think the accompanying explanation would help understand it a lot easier.

    (Also typo: “Explicitely” slides 19&20)

    • Hartmut Kaiser says:


      thanks for the typo correction. This is fixed in the referenced document now. The accompanying explanations will follow over the next weeks as new articles on this site.

      Regards Hartmut

  3. Bernard Hugueney says:

    Awesome ! 😀
    This is the coolest C++ code I’ve seen in a long time !

    The only sad thing imho is that a large part of the code is reimplementing a custom variant and a custom list as explained in . Just out of curiosity, do you now if you could have reused/will be able to reuse Boost.Intrusive lists with the new relaxed POD of C++0x ?

    And for a wild dream : Do you think it would be possible to make a compile-time scheme interpreter using the trick described in ?

    Best regards,
    And keep up the good^W amazing work !


    • Joel de Guzman says:

      Re: custom variants and lists, yeah I did take a look at intrusive. My initial results were not quite good, I don’t recall exactly why but I can get back to you on that (perhaps look at it once more). I haven’t looked at C++0x (or is it C++11 :-). I’ll have another round of experiments again to get the best implementation of this rather important piece of code. I also have an eye on Larry Evan’s variant implementation which looks pretty nice. We do intend to have it in spirit support.

      • Joel de Guzman says:

        Oh, now I know why. You can’t use intrusive in such a way that the element type is itself (recursive). Try it.

        • bernard says:

          Thank you very much for getting back at me on this matter. I’ll try to understand if there is a fundamental reason for Boost:intrusive not to be able to handle recursive type or if this shortcoming is only incidental.

          Best Regards,

  4. bernard says:

    Btw, it might be a stupid question but.. why are you not interning the immutable strings (boost:fly_weigth) and storing just pointers to the interned string ?

    PS: in scheme/interpreter.hpp couldn’t the argument_function specialisation be replaced by putting “while (scoped && level != eptr->level())” (note the added “scoped &&”) in the eval() of the generic case@line164 .

    • Joel de Guzman says:

      You think there’s advantage in doing so? Wouldn’t the need for locks and stuff negate the advantages gained for smaller sizes? I’m not sure. Would you be interested in investigating that route with some timing tests to see if it’s really worth it?

      Re: PS: Good catch! 🙂 You are right.

      • bernard says:

        I do not know if there would be an advantage in doing so. There would have been if it had allowed you not to roll your own string implementation (which is great btw 🙂 ) but this point is now moot. Furthermore the advantage of simplicity would stand only if you do not support mutable strings for which your implementation would still be needed.

        As far as efficiency is concerned, there as memory and exection time considerations. I haven’t checked if your fast_string implementation is responsible for the utree size and if replacing would shrink sizeof(utree). For strings that do not fit in the local data of the utree, the gain would be obvious but I don’t expect a lot of copies of large strings in a typical scheme program.

        For execution time I think it very much depends of :

        mono or multithread execution : the global state of interned string would incur a synch penalty only in the later case. However, most lock would be non -exclusive read lock that would not impose a contention. This is however very much data dependent.

        The runtime impact would mainly depend on the number of ‘new’ strings read from the scheme program (they would incur a larger cost when interned) vs. number of searches or test for equality (they would be much faster with interned strings with equality -> identity). For a typical program I would expect the later to outnumber the former by a very large factor (you read a function once and apply / recu n>>1 times). That is why I believe that scheme implementations intern symbols (although I confess that I never checked).

        However, I’m not sure that speed is of essence for a interpreted language. Imvho, it is a kind of a lost cause without JIT, and I’d rather have seamless interoperability with a compiled language for the (hopefully rare) parts that need high performance.

        But if you have some benchmarks, I might try to check the impact of interning symbols :). ( But don’t hold your breath, my spare programming time was recently lured away from C++ into Clojure. Btw, I’d *much* rather have a scheme with C++ interop. than a Clojure with java interop . 😉 )

        Best Regards,

Leave a Reply

preload preload preload