Chicken Scheme | Hacker News Reader

Chicken Scheme

call-cc.org

111 pointsjrajav61 comments

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]

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

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.

It really does. This dissertation explores the differences with other implemantations [PDF] http://www.cs.indiana.edu/~dyb/papers/3imp.pdf

I'm totally going to read that.

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.

>Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables?

Same way you do it in C/C++/Java etc with their threads? Not really a unique to closures problem.

>(To get what you want in a Lisp you need to apply either Erlang concepts (...) or Clojure concepts

Or this fancy CSP thing? (Is it similar to Erlang? I don't know Erlang).

The Chicken website has some good information for programmers coming from other languages:

Chicken for Ruby programmers: http://wiki.call-cc.org/chicken-for-ruby-programmers

Chicken for Python programmers: http://wiki.call-cc.org/chicken-for-python-programmers

Chicken for PHP programmers: http://wiki.call-cc.org/chicken-for-php-programmers

Chicken for C programmers: http://wiki.call-cc.org/language-comparison

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! :)

[1] http://gambitscheme.org/wiki/index.php/Main_Page

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.

A list of packages (called "eggs") is available at http://wiki.call-cc.org/chicken-projects/egg-index-4.html

(Disclaimer: I don't know much about Gambit, and cannot comment on their respective implementation capabilities.)

Gambit is extremely fast, that's its main benefit over the competition. It's ecosystem is... very rough, though.

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.

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.

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

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.

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

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.

[1] http://wiki.call-cc.org/man/4/Deviations%20from%20the%20stan...

[2] http://gmplib.org/

(I use Gambit but not Chicken)

FYI, this hasn't been true for 3 years now: http://lists.nongnu.org/archive/html/chicken-users/2010-03/m...

Thanks for the pointer.

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 ?

[1] http://wiki.call-cc.org/eggref/4/numbers#compiled-code

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.

I remember some horrible compilation issues with this library while I was trying to get some academic code running - they used the rationals in GMP.

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.

http://en.wikipedia.org/wiki/Racket_(programming_language)

Are these compatible?

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

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]

[0] https://a.keeptherecords.com/demo, source code: https://github.com/ThomasHintz/keep-the-records

[1] http://thintz.com?hn=t

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.

http://docs.racket-lang.org/r5rs/r5rs-mod.html

I'm considering a lisp dialect for a personal project (REST Api w/sqlite embedded in an ARM device running linux).

I'm evaluating racket, clojure, even IronScheme over mono.

Do you recommend using Chicken Scheme, what are his advantages/disadvantages over the other languages mentioned earlier?

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've been trying clojure in IntelliJ with La Clojure plugin and it works pretty well.

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.

I use https://github.com/benmills/vimux for vim/tmux plumbing.

I've evaluated other schemes as well and built my personal site and a few web apps in chicken scheme.

Why do I love it? It can be fast, very fast. You can embed C code if it isn't fast enough.

It is very practical, there are many libs. It compiles to C which makes it pretty easy to add support for many popular libs that are written in C/C++.

A lot of schemes sacrifice speed and practicality for academic reasons, chicken scheme doesn't do this.

The community is fantastic. Everyone is reasonable and kind and helpful.

For anyone who still has a GP2X lying around: I uploaded a Puyopuyo clone to http://dl.openhandhelds.org/cgi-bin/gp2x.cgi?0,0,0,0,25,2919 a week ago, written in Chicken + SDL. My first ever Scheme/Lisp project...

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

There is at least an immutable maps implementation here, http://wiki.call-cc.org/eggref/4/persistent-hash-map

Not too sure about the others though.

I guess maps is the structure I'm most keen on. Thanks!

Its community is great.

I second this. Chicken's community is the friendliest and least toxic I can think of.

What about it?

Advertisment.

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

Sounds more like a toy to me.

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.

Languages are a lot like startups, they take forever to gain traction.

Chicken scheme had been around for 12 years... How did this make the front page?

Only brand-new links are allowed on the front page?

Hopefully that's never the rules. However, the title could be more informative, apparently there was a minor version release 3 days ago.

I found it informative. I'd never heard of Chicken Scheme.

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

More info on this, for anyone who's interested: http://stackoverflow.com/questions/8859486/other-references-...

I submitted a link approximateley 5 months ago for the 4.8 release which received 2 upvotes. Shows the hit-or-miss nature of Hacker News.

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.

For instance:

https://news.ycombinator.com/item?id=2241015

https://news.ycombinator.com/item?id=3440777

https://news.ycombinator.com/item?id=3297071

I find it much more tiresome when people complain that something is not news.

I am not complaining about the link not being news. I am complaining about the lack of explanation about why it is relevant today.

This is similar to if somebody would post stuff like:

Mono C# compiler [http://www.mono-project.com/CSharp_Compiler]

Pypy [http://pypy.org/]

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.

Am I alone with this?

I agree with you.

Thanks :)

Then don't complain. Either figure out what is new and point it out to start discussion on that, or just move on.

Actually I find it quite good, given that the average age in HN readers seem to be quite young, given what I see in certain comments.

So it is good to share knowledge from old stuff.

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.

Reply on news.ycombinator.com