An opinionated guide to Scheme implementations (2013)
wingolog.org
wingolog.org
Apparently Cisco bought Cadence, and Chez Scheme fell through the cracks.
Ugh. As far as I know, perhaps not counting the 2 JVM Schemes, it was the only one that provided OS level non-green threads.
Thanks for the tip!
Repeated from the other reply on Guile: Hmmm, now I'll have to narrow the statement to "The only native code compiling Scheme that I know of" (which is harder to do).
If you play Philip Glass' Einstein on the Beach while using it, it will not be happy!
(We were roommates when he launched the GNU project, and he did not like that title, it would wake him out of a sound sleep. Which, if you've listened to it, is perfectly understandable, it's very minimalist, an acquired taste he did not share :-).
Hmmm, so it does, and as suiting its niche, at a low level. See above WRT Gauche; from a skim of the manual, Guile's VM may be reentrant or it hides that level of detail.
Thanks for the tip!
Hmmm, now I'll have to narrow the statement to "The only native code compiling Scheme that I know of" (which is harder to do).
Native compilation is on the roadmap for Guile, so hopefully you'll have to narrow that statement further in a couple of years. :)
In that state, I'm pretty sure most people prefer Cage.
http://www.centurylink.com/business/asset/channel/cisco-us-g...
The web site doesn't look like it's been touched since 2011, and Google searches constrained by site:cisco.com turn up nothing. Other searching showed no signs of life.
Please don't do this on HN. Even if it's true, the health points it knocks out of the discourse are more valuable than the truth that it adds. The thing to do with comments that suck is downvote them. If you have a factual correction to add, that's great, but let it stand on its own. ("Guile uses the LGPL, note the 'L'." is just fine.)
1. No GC. Ref counting is sufficient for my own use.
2. Integrating with the C/C++ libraries I want to use is a lot easier. I designed my implementation for the purpose of embedding in my project and gluing libraries.
I've done this for a Java project many years ago, where it sort of grew out of a config file format, as so many Lisps do. I would probably take the trouble to add a standard embeddable interpreter if I did it again. Otherwise, you end up with yet another 80%-ass Scheme with its own quirks and no libraries, and the world has too many of those already.
1) adapting your native libraries to a standard implementation
or
2) adapting your implementation to your own libraries
I decided that I mainly want Prolog to interact with, not to write a large amount of code in. So for me 2) was more advantageous.
I forgot to emphasize that this is not a real problem. You will likely have good C/C++ libraries for most things. The real issue really is to expose these libraries to your embedded language on a as-needed basis. To me the effort is better spent in creating my own targeted solution that makes interfacing easier and that is under my control than learning the minutia of the FFI of a third party implementation, after taking into account the following:
1) we are talking about effort on the scale of one or a few KLOC to roll one's own, and comparing that against the effort needed to truly master the FFI of a third party implementation;
2) my interface is no longer limited to the lowest denominator that a standard implementer would face (e.g. most use C but I can use multiple inheritance and templates of C++ to make the interfacing a lot easier);
3) supporting FFI users is typically not the highest priority on the standard implementers' agenda (if there is any support at all).
For most things in your domain. Then someone wants regexps, or Windows path handling, or what-not, and you find that you didn't really implement Scheme macros, or some particular style of modules, so you lose.
I agree that if you want C++ integration, you're probably going to want to roll your own. The first person to write an easy FFI that groks C++ name mangling will do a tremendous service to mankind.
The real issue with this approach is that, if you need a particular library you have to do the bindings yourself first. You have to deal with the delay required to design, implement and test it. On the other hand, the difference between learning the API for an another popular language and learning the native API so you can make the bindings for your language tends to zero as the complexity and size of said library goes up.
I think you would be hard pressed to find something that is available in Scheme but not C/C++. Take regex, you have std::regex, many pcre wrappers and Google re2, which has strong linear time guarantee. If you go with chibi as recommended by the blog, does it come with a good regex binding? What if you want to use Google's library? By the time you figure out how to bind iterators or coroutines in c the effort may well have been used to roll your own c++ solution in the first place.
"you didn't really implement Scheme macros"
I agree that is a more serious barrier. One has to honestly assess one's own true understanding and ability in implementing the target language. I am not an expert in Scheme and I couldn't tell you how easy or hard this is. I did study Prolog and its implementations extensively so I knew exactly what I needed to do. There are so many good resources out there that if one is willling to put in the effort one will be richly rewarded for the learning experience.
[Disclaimer: I also like the idea of RSR7S small.]
Just now there is a major reorganization in the Racket repository. The idea is to split it in a core part and may small packages. The objective is one day having many installers. For example one with only the minimal support for racket, one with everything including the kitchen sink, ...
Bloat is a content-less word for software.
Most naive users complain about "bloat" for stuff like program file sizes on disk, not knowing that most of it is assets (icons, etc).
Others think that having two many options in the menus, features etc slow the program down, not realizing that in most programs stuff is run and loaded dynamically, and a features you don't use don't affect the speed at all.
Others yet think that only 20% of the features is needed (those that THEY use, of course) ignoring the fact that while a core set of features is common to all users, a large part of them are in non-overlapping set. E.g.: "Who needs a word-counter in Word?" -- well, if you're a journalist, it's your #1 more useful function.
I still think it's a far superior way to introduce newbies to Scheme than emacs, but it's definitely flawed.
If you are really resource constrained it's easy to go to the settings and restrict memory use, and turn off tools you don't intend to use. If you have a really slow machine there is even a minimal DrRacket.
My most powerful personal computer being a laptop with an 1.8GHz i5, and 4GB of ram. Yeah, that's very modest by 2014 standards, but I really think that it should be able to handle DrRacket better than it does. As it is, it is just too slow for me to put up with. I think that something that at least somewhat targets the education niche should be able to perform well on old hardware (the type of machine you might typically find in a university computer lab).
1) Turn off the background syntax checker (click the dot in the bottom right corner).
2) Turn off "Program contour" in the "View menu" if you happen to have it on.
If that's not enough:
3) Use "Limit Memory" in the "Racket" menu to limit the memory use for the user program to say 256MB.
4) For more speed: In the language menu use "Choose language...", click the "Show details" button and turn ofd debugging. (But that's a last resort)