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!

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.

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.

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.

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?

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 . 😉 )