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