S2 Project Diary

I'm stealing SourceForge's idea about keeping diaries. Since I haven't figured out how they run their diary system, this page will have to suffice for the moment. The point is to keep interested observers updated on the progress of S2 development, especially since this is a part-time project for me and subject to periods of inactivity.

And another thing: the 'Forge says that browsing the CVS repository is a good way to get a clue about the status of the project. Not for me. You're way better off looking here. I commit frequently. I commit broken code. I leave useless comments on check-ins. I reorganize the directory structure. Get an accurate picture, read the diary.


I've actually been quietly working on this stuff all through the last year. The main reason that there's been no diary entries is because I was electrocuted at the beginning of April, 2002.

So enough of the sympathy. Gambit works! I think it may well be time to announce version 1.0, even though I've had to deprecate Bigloo, PLT, and Scheme48. Actually PLT and S48 are probably fix-able, but I'm just too tired of wrestling with S2 for Bigloo. I seem to have hit every weakness in the Bigloo implementation. sigh

The installation procedure has now been simplified. (configure; make bootstrap) should be all you need to do.


There's nothing like using code to polish it. The library code works pretty good. I've slurped into the official release Oleg Kiselyov's SSAX code, pieces of Aubrey Jaffer's SLIB, a few of the SRFIs (specifically numbers 1, 8, 11, 13, 14), and some of the SCSH interfaces.

The down side is that Scheme48 support seems to be broken. Actually it is broken, since Scheme48's (eval ... (scheme-interaction-environment)) doesn't seem to include the code of the running program. I'm sure it's some kind of module system issue, but I'm using it as a motivation for finally writing a portable eval.

Other bad news: I get core dumps when I try to build PLT and Chicken on my poor lame (x86) box. S2 passes fixpoint for those platforms on Solaris, so I suspect that it's a memory issue with my tiny box. Anyway, I'm rewriting the reader so that I can drop the call/cc coroutining with the Essence parser, it *is* a bit of a memory hog. Besides, this should speed things up quite a bit.

And the rewriter code is too slow, too.


We appear to have library support, although it's a bit of a pain to install files into the library at the moment. This might be a redesign issue; it might be a utility-building issue, I'm not sure yet. We're also going to need to add another special form to the S2 language to ensure that certain forms get placed in either the prelude or postscript of the mangled file. I'll post more here when I get the semantics fully worked-out.


Woohoo! S2 now has support for define-macro! Plus a number of other features, most notably SRFI-9 support which generates code optimized for whichever specific platform you target.

There is also an examplesdirectory in the distribution which contains the code that I used for benchmarking some Scheme systems. This code was at the core of a thread on comp.lang.scheme due to my surprise at the results from a naive approach to benchmarking. I've excepted some of the messages on this web-site, for the full thread you'll need to go to Google and check out the following threads:


A lot has been going on. The --target mechanisms are much better integrated (although I need to be able to load a target defn from an external file); Chicken is now a supported substrate, although only in the interpreter (the compiler is coming RSN); Scheme48 module support appears to be working fairly well (no promises, I've only made basic tests); and I've been using S2 in a RL project.

I can't say too much about the RL project due to intellectual property reasons, but as a spin-off I have generated some interesting benchmark results. The code for them is also included in the all-new examples subdirectory. Sorry, I haven't quite gotten as far as writing real documentation, but then AFAICT, nobody's using S2 yet, anyway. Sigh.


We've got fixed-point Again!

Early AM 5-June-2001

Made several changes to the semantics of include and import clauses for the Bigloo module system; mostly to fix bugs. The import code was not recursively walking through the include files, leading to an incorrect calculation of the dependencies and an incorrectly ordered output file. This seems to matter for PLT, anyway.

Also added the first extension to the Bigloo module system, a begin clause. It has the same semantics as the Scheme48 begin clause, and is necessary because the Scheme48 support gets confused about what module initializers should get run in. Or perhaps more accurately, the Bigloo module system doesn't provide enough information to determine what module top-level expressions should be run in if multiple module forms are allowed in a single source file.

Bootstrapping this has been real fun. I'm needing to hand-patch these changes into the stable S2 because it doesn't generate valid code, and the source code no longer bootstraps on raw Bigloo. sigh...


I've still been too bogged down in RL (for-pay) projects to make much progress. (sigh) Oh well, my options will eventually vest. Anyway, I have split out the option-processing code from S2 and made it available on the snippets page.


Got an inquiry from the SRFI people today. They wanted to know if they could consider S2 to be an implementation supporting SRFI. I told them "No, not really", but it's quite motivating to get back on the horse and finish this development step anyway.

It's getting real close to working again. I just need to get Bigloo include files to work and I should be back to fixed-point. Then we can see if we've made enough room for full Scheme48 support.


Real-life has overtaken development on S2 for the last little bit. Nevertheless, I've been slowly working on multiple module definitions for each source file. This has caused nearly a complete rewrite of the core module code. Things are starting to come back together, but tag stable is still the only thing that works. There should be a new release within a month or so...


First tests of Scheme48 module language parser. It worked first time! Needed to add a little hackery to the expand-file-name (& friends) code to handle the Scheme48ish method of finding files (paths, if relative are relative to the module file's directory). Unfortunately it doesn't handle symbols as file names correctly, even though this is legal S48. Will fix RSN.

The S48 support also needs to handle multiple module definitions per source file better, as this is quite common in the S48 world. Currently, we only lose small: it loses all module names but the last, although it does bring in all the relevant source code.

Also improved support for --incremental, which had the nasty habit of making a null module for each occurrence of a missing module.


First time hacking on S2 in a while. Added --incremental switch to ease the transition into handling Scheme48 modules. Basically, until I get the library code fully implemented, I'll be having missing modules in Scheme48 code. --incremental is supposed to put a comment in the output file at the right place telling you that it needed a module, but that doesn't quite seem to happen. Otherwise it works OK.


Well, Matthias Blume has released maintenance of VSCM to me so I should be able to fix/work around the issues with the TR bug in it. Actually, I'm planning to fix it, but that's all just part of my plot for World Domination (TM) bwah-hah-hah-hah!!!

I've also done some work towards getting a fixed-point for Chicken, mostly because its a fairly conformant R5RS implementation. I'm also having prblems with the reader under it. Could it be that my lexical analyzer code is not as portable as I thought it was after four fixed-points? Naahhh.

Well maybe. Anyway, I'm resurrecting the reader test programs to make sure. See reader/Makefile.in for the latest changes. Targets test-lexer and test-reader should start working Real Soon Now.


VSCM has a bug in its TR handling which breaks the full-reader, I can work around it but the workaround's ugly. I'm corresponding w/Matthias Blume about it, but it is unclear what will happen.


It has been pointed out to me that I have an invalid email address on these pages. It should be fixed now. I'm a bit buried in Real Life to make much headway just at the moment. There should be a new version soon.


Setting up the "standard" libraries that will ship with S2. For the moment, that means just the SRFI libs (although SRFI-13 and SRFI-14 are dependent on significant quantities of non-R5RS stuff. Thanks Olin. Sigh).


Basic support for Matthias Blume's VSCM. It limps, but I've not done anything yet to deal with portability to this substrate. VSCM has hygienic macros, so I suspect this port to become another fixed-point. Just not today. It needs at least:


Got fixed-point back on all substrates. More hacks on make clean. Major updates to the bootstrapping page. Put the last diary entry thang on the front page, but I'm not sure if I'll keep it. It's too easy to let it get out of date.


Hacked in basic restructuring of rewrite strategies. It mostly works. Hacked make clean fairly heavily to be much smarter. Fixed a minor bug im bootstrap/rules.mk that broke make s2-larceny.

The automatic selection of substrate is really nice.


New Makefile structure seems to work. Guess it's time to document it. Bootstrapping works well. Moving on to handling the Scheme48 module system and generating output which avoids inter-module name crashes. Attaching the stable tag to this version.

Also added a lot of text to the front page, although I haven't really made it clear that the module-system issue was what got me started. Oh well, I've said it here and I'll make it more clear when I have broader reader support.

Mostly 6-October-2000

Deep-hacking the Makefiles so that you can bootstrap and install (almost) without knowing what you're doing. Not really sure how much I like autoconf, but having a clean configure/make cycle makes the project feel much more finished.

Factored Makefile and bootstrap/Makefile into substrate-specific portions. configure picks what I think is the best substrate from the Schemes that are installed on the system. This needs documented, but for now folks can just look in configure.in.

Figured out the brokenness under PLT. Mea Culpa. The fine Piled Higher and Deepers responsible for MzScheme made unit a reserved word. NBD, as I already had Makefile gee-whizzery to handle it, but it only worked if the PLT bootstrap was built on the Bigloo substrate (it was dependent on Bigloo's upper-casing). I've got what I think is a fix in now, but testing it will have to wait a bit.


Bigloo, Larceny, and Scheme48 have reached fixed-point again! In theory PLT should also be at fixpoint but it's quirky extensions have gotten in the way. (Again!) It's frustrating because the PLT substrate is so good in so many ways (among them being that it's fast). Oh well, it will get fixed later.

Tagged the source tree as stable. I'll upload a tarball as soon as I can figure out how to do it on the 'Forge. Still not ready to announce on c.l.s, though.

Various web twiddling, including status page and a start on a discussion of the fixpoints (as in recursion theory, not bug-reporting). Minor front page hacks.

COB 3-October-2000

Twiddled the web pages even more. Hacked on the autoconf stuff until it hurt and blew away all the Makefiles in the process. Thank God for CVS. Have blufgeoned everything into a semi-working state. Haven't gotten to fixing the fixpoints.


Early AM, 3-October-2000

Trying to make the code somewhat presentable. Unfortunately, I seem to have broken the fixpoint *tests* with the srfi-0 support rather than breaking the mangler. It's hard to tell. I'm cleaning up the Makefiles and plugging in Autoconf in an attempt to get a better handle on the whole bootstrapping process. Since this is essentially what the fixpoint tests do, I expect to fix them as well...

Use XEmacs! SourceForge
David Rush
Last modified: Tue Jul 1 22:07:34 IST 2003