I would highly recommend chicken scheme for most projects. It isn't as mature as other ecosystems, but it is getting there fast and is already quite mature and practical. I've used it to build multiple web apps/sites.[0][1]
The absolute most interesting thing about Chicken Scheme is the way it does allocations and garbage collection. I've wanted for a long time to make the time to add a always-on cpu and memory profiler to Chicken Scheme that just tallys the "return" addresses during the gc, meaning at each cg cycle you have a pretty darn good tracing profiler, and keeps the "return" addresses in cells when they are moved off stack, so at any moment you can blame your memory usage on particular code. Clearly you could do this sort of thing with a lot of runtimes, but Chicken's design really lends itself to it.
Also, I'm really interested in the debug-ability of Chicken. Instead of a stacktrace, which sort of captures "where you're going", a stacktrace in Chicken captures "how you got here", which in conjunction with using immutable data structures would make the most absolutely amazing blob of data to be sent back by a customer - you could potentially restart execution with their data and step thru.
Chicken allocations and GC are a really great compromise between heap and stack memory. I've been looking into GC implementations recently and it's one of the most interesting.
Another one I think is interesting is Lua's with the "upvalues" -- objects are on the stack unless they survive the frame they live in, in which case they are moved to the heap. But they implement it with a double dereference, so it has its own downside.
Chicken Scheme and it's use of Baker's "Cheney on the M.T.A." allocation and GC is intensely neat ... but correct me if my analysis was wrong: isn't it inherently single threaded?
(No problem for a lot of people, but my particular area of interest is making SMP/ccNUMA systems sing. In Lisp. :-)
Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables?
I don't know if Chicken Scheme allows multiple distinct instances of the run-time in one process -that would be very cool, and if anyone knows please do tell here-, but it can't safely support multi-threading any more than any standard Scheme can.
To get what you want in a Lisp you need to apply either Erlang concepts (threads with distinct global namespaces, exchanging serialized data via messaging) or Clojure concepts (immutable state + COW techniques + special top-level, mutable variables with synchronization for all mutable state; but I repeat myself, since that's roughly what COW implies).
> Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables?
> To get what you want in a Lisp
Several Common Lisp implementations expose pthreads-style shared memory threads (SBCL, ECL, Clozure, Allegro, etc). It works just fine. The problem of synchronizing access to the closed-over variables in a closure is precisely the same as the problem of synchronizing access to instance variables of a class, and has the same solution: use a mutex.
What's the difference between Chicken and Gambit[1]? I've been reading about/playing with the latter for a few weeks, because of its interop with C (and therefore potential for integration with other C-friendly code, which is why there is an iPhone app that runs the repl.) My interest is that I'd like to write an application core in Scheme, and then write a GUI for iPhone, OS X, Linux and Windows, and I figured Gambit was best for this.
If I should be playing with Chicken instead, tell me why! :)
One thing is the relatively large number of packages available for Chicken, especially for C libraries on UNIX. Therefore many use Chicken for systems and desktop programming on UNIX.
Gambit also has (imho) a much easier FFI. (Once you get used to all the ___arg1 and ___result stuff.) So it really is easy to bolt on C -- and even C++ and Objective-C -- code to a Gambit app.
True enough. I have used Gambit for several apps in the last 10 years or so, but always for things that don't need a lot of 3rd party libraries. I wrote an article a long time ago on using Gambit for command line utilities and other small apps.
From the Chicken documentation [1] it appears that it does not include bignums in the core but as a separate package that requires GMP [2] to be installed. Since GMP is LGPL licensed this might cause an issue if you are sensitive to such things.
Gambit includes bignum support without external dependencies.
This note in the documentation for that egg looks worrisome [1]: "IMPORTANT: This only works when the code will be run on exactly the same platform as the Scheme compiler ran on. Cross-compilation and compiling to C and compiling that on the target platform is not supported. (You will get an error message when you try to do it anyway)"
Does this mean that cross-compiling for iOS would preclude using this bignum egg ?
I have no experience with it personally, so that might indeed be the case. If anyone mentions otherwise on IRC (#chicken on freenode) I will update this accordingly.
My sense from looking at this same question before (although not doing anything, so this is just impression not experience) is that Gambit is being used more for embedded uses like what you are describing.
I've been interested in Gambit because it seems to allow fairly direct intermixing of Scheme and C code. I don't recall seeing Chicken being able to mix the two in the same file.
Chicken seems to have more libraries available and might be better for use doing things like Unix scripting or system tasks.
By the way, if you are interested in Gambit, and are on Debian/Ubuntu, I would suggest building Gambit from source rather than using the gambc package in the repo. It looks like that package is very out of date at this point. (It's actually been orphaned in Debian and I've been considering adopting it to bring it up to date.)
> I've been interested in Gambit because it seems to allow fairly direct intermixing of Scheme and C code. I don't recall seeing Chicken being able to mix the two in the same file.
Actually, it can. Just use a 'foreign-lambda' to embed your C code as a string, if that's what you want.
In fact, Chicken and Gambit's FFI are so similar that I managed to use an OpenGLES FFI from Gambit on Chicken with just a couple of macros to convert between them.
Thanks. I thought this was the case, but Chicken claiming that it compiled into portable C files rang a bell! In principal, my app doesn't need much more than a couple of local databases (files with S expressions in..) so I don't think extensive system library support would be much advantage.
I have built Gambit from source on both OS X and my Debian VM - no problems using them, but I haven't done anything remotely advanced yet.
It's nice that Scheme garners some attention on HN. It's more useful, however, when someone explains how they used it to build a business. Also, there are lots of Schemes and Lisps. Where does Chicken fit as far as libraries and support? Racket is the Scheme that I hear the most about.
I have built numerous businesses and websites with chicken scheme. It rocks.
The largest one is a basic CRM for a small niche. It runs super fast and development was a breeze. I run it compiled with a number of optimizations enabled.[0]
My personal website is also built in chicken scheme and runs fast even though it is running in interpreted mode.[1]
If by compatible you mean that the code are portable between them, the answer is maybe.
Strict R5RS code that don't use eggs (chicken libraries) has good chances to run on Racket. But note that Racket support stuff that is not even Scheme, hence the change of name from PLT Scheme
Racket supports running multiple (sometimes incompatible) dialects of Scheme through the use of a #lang directive.
If you prefix your program with "#lang racket", you get the definitions for the full Racket language, with all of the extensions and libraries that Racket provides.
But if you want to preserve compatibility with the standard and with other implementations, you can prefix your program with "#lang r5rs". It derives from the same base language as Racket.
Chicken Scheme is purportedly very fast (which might be important for your project) and has a friendly, knowledgeable community behind it.
It's also BSD-licensed -- not so important for a personal project, but nice if you want to build a commercial product in Scheme. Gambit Scheme also has this (it's available under the Apache 2.0 license).
I've never used Chicken Scheme (only Racket), but I've read a few articles about it and the advantages seem to be:
-Compiles to C, so it's highly portable and you get the performance optimization benefits of whichever C compiler you're using
-Lots of libraries
-Good packaging system, with packages that are cutely referred to as "eggs" (similar to Ruby's "gems" system)
Racket is great too, though, and DrRacket is an excellent IDE with minimal install/configuration difficulty. It just works.
I'm not really sure what tools exist for Chicken Scheme. With Clojure, you're probably going to need to configure emacs or another text editor for syntax highlighting and REPL. I write Clojure in Sublime Text 2 with SublimeREPL but that requires some config and isn't technically free. There are Eclipse and NetBeans plugins, but I dislike Java IDEs for their enormous memory footprint.
I write for Chicken Scheme inside vim and tmux with some minor plumbing to send my selections/buffers to evaluate in another tmux pane that contains my repl.
This is basically the same thing you do for every other language when using vim/tmux.
Feel free to replace vim/tmux with $EDITOR/$TERMINALMUXER of your choice here, outside of emacs, which kinda does this already as long as you don't care about updating your repl buffer at the same time as you are editing code (say, whatever code you send doesn't return immediately because it's doing something time-consuming). vim+conque has this same issue as emacs, making $EDITOR/$TERMINALMUXER the only alternative if you want to use the repl to hack/dispatch big jobs.
Chicken, together with its eggs system has always struck me as very professional feeling. Plus, bind (dead simple ffi for C stuff) seems like a huge win where C is required.
That all said, I've become quite enamored of Clojure's various data types. Does anyone know if there has been an attempt to create things like immutable maps, vectors, and whatnot for scheme (esp Chicken Scheme)? I found a blog post a while back that talks about FSet for common lisp, but have failed to find an analogue for scheme. http://blog.thezerobit.com/2012/07/21/immutable-persistent-d...
"The disadvantage is that execution of Scheme code on multiple processor cores is not available."
So you're throwing away most of the computing power of a modern CPU. But other than that it's totally awesome I'm sure, after all who needs computing power.
In some ways it just encourages a different style of development. There is more emphasis on forking processes and communicating between them, which some may consider to be a better practice anyway. It all depends on your domain. On the other hand, there's nothing stopping you from binding to pthreads and seeing how far you get with that (and from a quick search it appears that people have had some success with it, especially if you're calling into a lot of C libraries).
Every time Racket or some other Scheme-like language is on HN I wonder why they aren't used more. It's probably just an illusion of the bubble I live in.
No, but it is hardly news if it had been around for more than a decade. If the poster finds that there is something new about it, a link to the specific item would be more helpful.
Those are interesting implementations for well known languages that aren't new. If I post them without explanation of why I found them interesting and relevant now, then I would mislead people and they might conclude that it is advertising.
Exactly. I'm young and found it interesting and useful. I was aware of Lisp but not Chicken Scheme specifically. It's nice to read a discussion about it.
I am reaching my 40's and sometimes I find the following issues:
- People get amazed at Go compile speeds, when Modula-2 and Mac/Turbo Pascal compilers were already doing that in the mid-80's
- People are talking about live coding and REPL, when it was already possible in the early 80's within Smalltalk and Lisp environments
- Some assume C is the only way to write operating system kernels, when there was a time operating systems were made using different system programming languages and C was just UNIX's language
- ...
This is why I think young generations need to learn about old technology.
I believe there was also a major version release (4.8.0) fairly recently.
I read some development notes a while back and one of the key features planned for 4.8.0 was a new optimizer based on flow-directed lightweight closure conversion; this is the same technique used in STALIN Scheme, which is widely considered to be one of the fastest known Scheme implementations (i.e., it produces the fastest compiled code).
Learn more about the features it provides: http://wiki.call-cc.org/man/4/Getting%20started
An index of the many libs it supports: http://wiki.call-cc.org/chicken-projects/egg-index-4.html
Why another lisp? http://wiki.call-cc.org/man/4/faq#why-yet-another-scheme-imp...
Getting good performance: https://news.ycombinator.com/item?id=5381472
[0] http://thintz.com?hn=t [1] https://a.keeptherecords.com/demo