S2 Fixed Points

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

• Chicken
• Gambit
• Larceny
• Petite Chez
• PLT

Of course, this leaves the question of bootstrapping the compiler unanswered. In principle, this is pretty easy on the certified platforms:

• configure
• make bootstrap
• make install

And if you want to check that the bootstrap version is correct, you can then run:

• test/fixpoint-<platform>

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.

Supported Platforms

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:

1. Larceny
2. Gambit
3. Chez
4. PLT
5. Chicken (interpreted)
6. Chicken (compiled)
7. Scheme48

Bigloo

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.

Caveat User:

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:

--reader naive

The naive reader uppercases all symbols and has no line-number reporting in error messages. It may actually work with current versions of Bigloo. I have also heard that Bigloo now has a case-sensitive reader, but the patch.bigloo and bigloo-target.scm files are not set up to take advantage of it.

--reader full

First it thrashes, then it crashes. This reader does call/cc co-routining, and historically Bigloo (particularly the Boehm collector) has had problems with this reader.

--reader native

This reader avoids the call/cc co-routining by building a recursive-descent parser on top of the --reader full lexer. 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 v1.01a

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.

Rice PLT v103, v20x

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.

Scheme 48 0.53

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.

Chicken

Interpreted

Interpreted Chicken is really slow, but it does work.

Compiled

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

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 petite 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 $*
    

The configure script looks for the EXEC= and HEAP= assignments in order to find the corresponding pieces of the petite installation.

Gambit-C

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 s2.gambit is bloody hard to read because of the lack of a macro-expander in gsc.