Like IronPython (well the initial one with the DLR that I based IronScheme on), IronScheme is compiled all the way down to IL level.
Furthermore, there are no interpreted parts in IronScheme (unless you call runtime symbol lookup that), as I have pretty much ripped out all of that from my 'branch' of the DLR, due to not being used and reducing the code footprint (I estimated I only used about 25% of the DLR, where the rest was rather Python-centric).
To see what IL gets generated, you can look at the ironscheme.boot.dll
assembly in Reflector .NET (using IL mode preferably, as C# tends to be restructured weirdly and just plain wrong in a few cases). This entire assembly is compiled by IronScheme. To see runtime generated code is a lot more trickier.
As said, this does have all the benefits of JIT, and with the optimizations I made on the DLR to be more Scheme-centric, it generally performed faster than IronPython when I last tested it (a good 18 months back at least, I realize IronPython has had quite a few improvements since then, but IronScheme was a few factors faster, even using Scheme that 'felt' more like Python to even the ball game).
Furthermore, I have attempted to utilize as much of the .NET framework as a foundation for IronScheme, and to make interoperability easier. Things like vectors
, byte-vectors
, binary-ports
and hash-tables
are based on the normal .NET classes we all know and use; object[]
, byte[]
, Stream
and Hashtable
respectively, to name a few.