The least fixed point of a recursive function is essentially the value for which the recursion stops. In the same way, the fixed-point of a compiler is the point at which it compiles itself. S2 has reached a fixed point on the following Scheme substrates (specific substrate limitations are detailed below).
Of course, this leaves the question of bootstrapping the compiler unanswered. In principle, this is pretty easy on the certified platforms:
And if you want to check that the bootstrap version is correct, you can then run:
Which will use the program you just built to rebuild it self and then check for differences. Nearly all the platforms have no differences; however, the Chez platform introduces some extra newlines at the end of the file on the second pass. This is not a real problem, ignore it.
S2 has been built on many versions of many platforms; however, keeping up with the changing environments is a constant challenge. Here are the Scheme implementations (and versions) where S2 is known to work. It is likely to work on other versions of these implementations, but incompatibilities do occur (PLT 103 to PLT 200 was a classic).
Additionally, some platforms are preferred by the configure script when it tries to build the makefile defaults. Generally the configure preference order is based on two criteria: speed and stability. Stability is generally preferred, but not strictly. The preference order is:
Bigloo was the original bootstrap Scheme implementation for S2. I still like Bigloo a lot. It has a nice module system and easy FFI (this was actually a design goal for the system). It can be very fast, and has good access to hardware features (like Z(2^32) arithmetic - it's amazing how many published algorithms depend on that implementation detail).
The Bigloo module system was used as the original module system for S2, and S2 used to be built directly from the sources using it, without going through the bootstrap step. This is no longer the case. S2 has extended the Bigloo module system and the extensions proved too useful to not use within S2 itself.
Unfortunately, Bigloo must now be regarded as a non-working substrate. There are now three readers built into S2, and none of them work terribly well on Bigloo. If you are interested in trying to fix the problems, all the makefile rules are still in place to build a Bigloo version, so have at it. In summary:
bigloo-target.scmfiles are not set up to take advantage of it.
call/ccco-routining, and historically Bigloo (particularly the Boehm collector) has had problems with this reader.
call/ccco-routining by building a recursive-descent parser on top of the
--reader fulllexer. Under Bigloo it appears to go into an infinite loop, and I can't help but wonder if this is due to Bigloo's difficulties with full TCO.
Larceny is currently the fastest substrate for S2. It also has excellent compliance to R5RS, and Lars Hansen has explained to me how to exploit his macro-expander from inside of S2 (but I haven't done it yet). The only downside is that it only runs on Sparc boxen.
The v103 code should still work but I haven't checked it in ages. Bytecoded PLT is really just too slow for this application, and I don;t really understand how to build a standalone,native-code executable for PLT.
Which leads to the other problem. Currently v20x is b0rken. I'm working on this, but it may take a while.
I should probably just remove Scheme48 from the supported list,
but it was the best platform for such a long time. The main
problem is that Scheme48's eval has unpleasant interactions with
it's module system - which means that we have to interpret
define-macros with an interpreter built inside the
interpreter. Blecch. It's really slow.
Interpreted Chicken is really slow, but it does work.
So you would think that if the interpreted version worked, then the compiled version would be a doddle. Well, it just ain't so.
Petite Chez works really well right now, and it's bloody fast
for a byte-coded system. That said, you have to be a little bit
careful with your Petite installation if you want the
configure script to detect and configure the
Makefiles to use it correctly.
The main problem is that the packaging is not
consistent across all of the platforms for which Petite is
available. Practically this means that you must hack the
shell-script which starts up
petite so that the
configure script can understand it. Eventually,
I'll make this work via
--with switches in
configure, but until then the
script must look like:
#! /bin/sh EXEC=/usr/lib/csv6.0a/i3le/./scheme.exe HEAP=/usr/lib/csv6.0a/i3le/./petite.heap exec $EXEC -h $HEAP $*
configure script looks for the
assignments in order to find the corresponding pieces of the
I am so pleased to finally have a Gambit version working. Now I
have a fast, portable implementation for
all the platforms I use. There are no gotchas of which I am
aware, although the mangled source file
is bloody hard to read because of the lack of a macro-expander