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.
Now that it’s been a couple of months since you switched, I’m curious how you like mzscheme — I’m thinking about making the switch too. Also, what Emacs Lisp lib are you using to talk to your inferior scheme? Thanks! –Rick
The same problem exists for other dynamic languages with multiple implementations. Switch from CPython to Jython or IronPython and you’ll find libraries that aren’t portable or extensions that don’t exist in other implementations. That’s the nature of the beast.
Having used PLT for a few weeks now, I think it could be considered the de facto implementation for Scheme. It’s actually useful for real world problems, not just teaching programming languages.
Now I just wish for something comparable to SLIME for the Scheme world.
Hi Rick,
The past few weeks I’ve been somewhat sidetracked working through HTDP rather than doing real work with mzscheme and I think that either chicken or mzscheme would work equally well here. However, for the few small scripts I have written, mzscheme has been the better choice. At least it solves the three problems I listed in the previous post.
I’m using quack to interface emacs with scheme and although I’ve not used most of its features, it works well enough for me.
Ian