I’ve had a good run with chicken, but it is time to admit it is not quite ready for my needs. On paper it looks pretty good – there are plenty of libraries, a nice and responsive little community and it runs on Windows and is fairly easy to compile to C. So where is it letting me down?
- I can’t get some of the libraries to work properly on Windows including
at least the full numeric tower and srfi-19 (date/time handling). - Also on Windows, it doesn’t run properly as an inferior-lisp within
emacs. I was trying to do some testing of the threading libraries and
unfortunately it didn’t return the responses asynchronously. - It still doesn’t handle white space within pathnames correctly which is
a problem if, for example, you want to run a binary that lives in
C:\Program Files.
All of these issues are down to the fact that none of the developers use Windows. Given sufficient time I might be able to fix them, but I guess I’m do not have enough motivation. Anyway, c’est la vie. It is a very nicely done project and I’m very impressed with Felix and co for putting it together, it simply doesn’t suit me.
So what next? I’m quite invested in scheme – I’ve put a fair amount of effort into learning the basics and I enjoy using it. Is there a free scheme implementation that will do what I need on Windows? I think there might be.
Mzscheme is another fairly complete scheme from the PLT family. It is actively developed and has a somewhat larger community than chicken scheme a correspondingly larger set of libraries. It also seems to be Windows friendly and indeed may be Windows-centric which is good. I avoided it originally because compiling to C is not the recommended approach and I have read posts from users that claim it is slower than Python. In fact, on some micro-benchmarks it performed rather well (at least in its JIT-compiled version 352 incarnation). These times are in miliseconds.
| Benchmark | chicken | mzscheme | python |
| binarytrees | 18047 | 14203 | 117453 |
| fannkuch | 21328 | 44469 | Error |
| fasta | 98250 | 39531 | 161953 |
| mandelbrot | 9359 | 32954 | 22172 |
| nbody | 12641 | 27781 | 42250 |
| nsieve | 8093 | 5985 | 12984 |
| nsievebits | 9781 | 6656 | 40781 |
| partialsums | 14735 | 40734 | 199906 |
| recursive | 45969 | 77734 | Error |
| spectralnorm | 222062 | No Prog | Error |
On the downside, a lot of useful functionality is not specified by R5RS and is therefore specific to a particular scheme. Mzscheme has this problem more than most implementations, I think because it is so much bigger. For example, the threading primitives provided are much richer than the fairly spartan srfi-18. Targetting Mzscheme would render my code _very_ non-portable. Let’s hope that I don’t want to switch again any time soon.
A Curious Programmer 
