Interesting discussion of some difficulties in designing a compiler for the Ruby language.
I am thinking a lot about the design of the runtime support library and the “foreign-function interface”. I’d like to avoid bolting on a big chunk of C++ support code for runtime support; optimally the language would be self-supporting, able to run directly on the kernel API, or possibly on the C stdlib. I haven’t worked out how this could be done yet; building those low-level abstractions into the language seems to conflict with the immutable/functional core semantics.
The purpose of this article is not to rehash excellent but previously published examples where software transactions provide an enormous benefit (though for background they are briefly discussed), nor is it to add some more examples to the litany. Rather, it is to present a more general perspective that I have developed over the last two years. This perspective is summarized in a one-sentence analogy:
Transactional memory is to
garbage collection is to
The prose style is excessively wordy for my taste, but the content is interesting, and the core idea is entirely compatible with my own opinions on the subject.