Guile is my second favorite scheme (after chicken). It's semi-R6RS, but still feels nice, and still feels scheme-y. It's nicely practical, and it's one of the rare Scheme implementations to support pthreads. Also, it has a lot of good libraries (behind Racket and Chicken, but better than many schemes), and an FFI that's actually pretty nice, but encourages writing a wrapper around the library that's more than paper-thin. It also embeds well, with it and Chibi being pretty much the only game in town on Scheme embedding.
Scheme is a standard. The most common standards for Scheme are R5RS, the controversial R6RS, and R7RS, which hews closer to R5RS. While there are reference implementations, there isn't really a vanilla implementation, as even the references add their own tweaks. Here's why:
Until R6RS, having a "vanilla" scheme wasn't practical: the scheme standard is minimalist, and excludes things like binary IO, modules, networking, OO, etc, although it does provide the tools to make your own module/OO system if you want. Writing portable scheme is almost impossible, and frowned upon.
R6RS tried to extend the language and stdlib, so that writing portable scheme was possible. It was criticized for being overly complex, and for forgoing common SRFIs (informal standards that can be implemented across schemes), instead coming up with its own solutions to the same problems. Its acceptance was mixed. Guile implements some of it, but there are few full implmentations of the standard. The lack of acceptance for R6RS is sometimes seen as one of the catalysts to PLT Scheme casting off the anchors of the Scheme standard, and renaming itself Racket, which was already starting to happen, as PLT steadily deviated from the standard.
R7RS was an attempt at a compromise: it provided the "small" language, already published, which is more based upon R5RS, and adds a module system and a few other extensions. The "large" language, still in development, will provide a large stdlib for doing Real Work. It will, however, notably lack a few things, such as an FFI, so while portable scheme will be possible, not all code will be portable (nor, I think, will all code ever be). Thus far, it seems to be going fairly well, with CHICKEN and Guile, some of the most popular scheme implementations, planning to support it.
Probably the closest thing to a vanilla scheme is Chibi Scheme, the reference implementation of R7RS. It's small, lightweight, and designed for static linking and embedding, like Lua. It has its extensions, of course, but they're fairly minimal.
There isn't really any such thing in the Scheme world. There are Scheme standards, but it's best to think of Scheme as a family of distinct, but closely related, languages instead.
Vanilla scheme is specified in "Revised⁷ Report on the Algorithmic Language Scheme" (R7RS, 2013); or the older R6RS (2007) or R5RS (1998).
There was a 1990 IEEE standardization of scheme (IEEE Std 1178), and last revised in 1995. But it isn't recognized as the canonical vanilla scheme like RnRS is.
I need to check out Guile's suitability for embedability in applications. Traditional suggestions have been TCL, Python, and Lua. For Guile, the conversation always focuses on FSF and Emacs, but that's boring. Has anyone [other than FSF/Emacs] used it as an application extension language? If so, what's your experience? What's the overhead? memory usage?
Ideally, I'd like to use it on embedded systems/firmware (as opposed to embedded in an PC application), but I'm assuming it's either too memory-intensive or requires too much platform support, and certainly the license won't fit :(
Guile's lib you have to link against is 2.5mb, and much of the object code for any Scheme you end up compiling is 0.5-3mb. That was enough to get Guile disqualified from our project.
I never managed to get it running on anything with less than 16mb of RAM, but that might have been my own C wrapper, YMMV.
This version of Guile makes possible better asynchronous code via https://github.com/wingo/fibers/wiki/Manual (which is the implementation of something similar to Python's async/await)
Lilypond (http://lilypond.org/). Though since guile 2.0 there's been some friction between the lilypond developers and guile developers. Lilypond is still using guile 1.8. There are periodic threads on the lilypond mailing list asking what the hold up is (I don't recall the reasons at the moment).
I think the lack of guile 2.0 support was mentioned as one of the main blockers behind full MusicXML import/export support - this was a couple of years ago though, not sure if that's still true.
There is no such big-ish projects using Guile outside projects embedding Guile and guix. There is no wordpress or even framework as powerful and easy to use as Django or Rails. There is no support for https, it's kind of a no-go if you want to access REST APIs from Guile. Cookie support is not good enough. That said, the creator of Artanis reported some success using Artanis in a commercial setting. Outside that there is various free projects in the work, look at Guile homepage or ask on #guile. On my side I am working on search engine named Culturia.
GNU Make has a Guile scripting interface, although distros don't usually ship it compiled into their 'make' packages (for whatever reason). On Ubuntu/Debian, you can get it by installing 'make-guile' instead of 'make'.
GNU Guix is part of the software deployment process for a pretty complicated speech recognition platform at the company I work for. Thus, I consider it real software.
As of GSoC 2014, I believe Guile Emacs works with only some performance regressions (I believe due to overuse of dynamic scope?). In any case, you can run it today if you wanted to, just follow the process outlined on the wiki [0]. That said, I don't think the Emacs project has fully committed to porting over for various reasons, probably in part because running Guile on some platforms (Windows) is really difficult, and thus would be a problem for users. I'm sure the people in #guile on FreeNode could give a much more detailed answer though, I don't follow the Guile/Emacs thing so closely as I'm mostly a CHICKEN Scheme / Vim user.
It's not the language. I don't really like Scheme (I'm more a Common Lisp guy). I would, however, really love to see Emacs without the Emacs Lisp limitations because everything missing from Emacs - at least to me - is performance. Guile looks like a good way to work around that.
Also, from a back-of-the-envelope calculation from the ohloh.net numbers, Emacs has ~1.1M LoC of ELisp.
With that kind of number, you're pretty much guaranteed some elisp is going to stick around forever (especially considering Emacs' glacial [but improving!] rate of change).
Readit News
I love it, just not as much as I love Chicken.
By that I mean what is the default/main/vanilla scheme?
Until R6RS, having a "vanilla" scheme wasn't practical: the scheme standard is minimalist, and excludes things like binary IO, modules, networking, OO, etc, although it does provide the tools to make your own module/OO system if you want. Writing portable scheme is almost impossible, and frowned upon.
R6RS tried to extend the language and stdlib, so that writing portable scheme was possible. It was criticized for being overly complex, and for forgoing common SRFIs (informal standards that can be implemented across schemes), instead coming up with its own solutions to the same problems. Its acceptance was mixed. Guile implements some of it, but there are few full implmentations of the standard. The lack of acceptance for R6RS is sometimes seen as one of the catalysts to PLT Scheme casting off the anchors of the Scheme standard, and renaming itself Racket, which was already starting to happen, as PLT steadily deviated from the standard.
R7RS was an attempt at a compromise: it provided the "small" language, already published, which is more based upon R5RS, and adds a module system and a few other extensions. The "large" language, still in development, will provide a large stdlib for doing Real Work. It will, however, notably lack a few things, such as an FFI, so while portable scheme will be possible, not all code will be portable (nor, I think, will all code ever be). Thus far, it seems to be going fairly well, with CHICKEN and Guile, some of the most popular scheme implementations, planning to support it.
Probably the closest thing to a vanilla scheme is Chibi Scheme, the reference implementation of R7RS. It's small, lightweight, and designed for static linking and embedding, like Lua. It has its extensions, of course, but they're fairly minimal.
There was a 1990 IEEE standardization of scheme (IEEE Std 1178), and last revised in 1995. But it isn't recognized as the canonical vanilla scheme like RnRS is.
Ideally, I'd like to use it on embedded systems/firmware (as opposed to embedded in an PC application), but I'm assuming it's either too memory-intensive or requires too much platform support, and certainly the license won't fit :(
I never managed to get it running on anything with less than 16mb of RAM, but that might have been my own C wrapper, YMMV.
Edit: This looks to be the issue: https://lists.gnu.org/archive/html/guile-devel/2016-06/msg00...
That is not true. While Guile doesn't support HTTPS out-of-the-box, gnutls ships with Guile bindings. Guix is a notable user of those bindings.
[1] http://web-artanis.com
[0] https://www.emacswiki.org/emacs/GuileEmacs
I hope it does. The original vi's lisp mode is something I have only seen traditional vi implement thus far, and it's pretty nice.
With that kind of number, you're pretty much guaranteed some elisp is going to stick around forever (especially considering Emacs' glacial [but improving!] rate of change).
Seems like it's not to far from being stable (if not perfect performance wise).
( Sorry )