So I've long wanted a good scheme for CLI programs. I've evaluated Chicken several times and passed over it every time.... but I can't remember why. Here's what I'm looking for:
1) Fast executables
2) No runtime requirement
3) Good ecosystem (for Scheme)
4) Good ffi (though I'd prefer a great ecosystem).
That's basically all I want. I also kept going back to Gambit but it fails at #3 which Chicken seems not to.
Is there a gotcha for Chicken that I'm not remembering? Like how Racket has a slow startup cost, Chicken doesn't seem to have that (from my testing). I think Gambit is probably still faster but not by much (I could be wrong here).
As far as I know chicken meets all of those requirements quite well. Chicken starts up extremely fast even for very large applications as long as you compile it.
The library ecosystem is obviously not as well developed as a major framework like rails or django but it is growing fast and covers most things you would need. A large benefit of it compiling to C and having great FFI support is that most libs don't have to be reimplemented in scheme but can just have a binding to an already mature lib.
edit: And if it doesn't have what you need the community is great at helping you get on the right track adding a new lib and gladly accepts well done patches.
Maybe You should newLISP (www.newlisp.org) give a try. I'm using it for my CLI programs (like Dropbox background syncing, web scraping). newLISP scripts can be linked to portable executables :-)
The only thing I heard about (I think, don't remember that well) newLISP was a statement that the language lacks lexical scoping because the author didn't know how to implement it.
Is it true (I mean dynamic scoping)? If so, why was the choice to exclude lexical scoping made? Is it practical to write a bit larger apps/scripts in newLISP?
IIRC the author wanted simplicity was the reason invoked by the author. Newlisp has dynamic scoping and contexts (namespaces), in which you get lexical scoping, plus other features.
For instance when you want to close some function over some variable, one creates a new function by expanding the free variables inside the existing function (or lambda), to their local value at runtime. Which shouldn't be too much expensive if used in a smart way, I guess.
This might be a bit weird, this and the Only One Reference (ORO) memory management strategy, but Newlisp executable is very small with regards to the craptons of functions that are included in the core. I could make it on a low-end 32bits micro-controller, where few interpreters can pretend to run at acceptable speeds and/or fit (a couple MB of flash space).
The context and ORO thingies may be use in conjunction to use what they call "FOOP", for functional object oriented programming. The association of both paradigms, in theory, should let users scale to larger applications, assuming they can grok it.
Dynamic scoping is true. But I've never encountered any problems in my large newLISP projects, because I'm working in small modules (newLISP calls it Context).
Like a Scheme closure a newLISP context is a lexically closed space.
I agree with you re: Gambit. Gambit is great for small fast standalone executable where you don't need 3rd party libraries. Gambit's weakness is the lack of a large set of libraries for web apps, etc. That said, Gambit is the Scheme I have used the most in the last 10 years.
1) Fast executables 2) No runtime requirement 3) Good ecosystem (for Scheme) 4) Good ffi (though I'd prefer a great ecosystem).
That's basically all I want. I also kept going back to Gambit but it fails at #3 which Chicken seems not to.
Is there a gotcha for Chicken that I'm not remembering? Like how Racket has a slow startup cost, Chicken doesn't seem to have that (from my testing). I think Gambit is probably still faster but not by much (I could be wrong here).