Archive for September, 2006

Switching scheme implementations

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.


Read Full Post »