GNU Guile 2.1.4 released
lists.gnu.org
lists.gnu.org
I love it, just not as much as I love Chicken.
By that I mean what is the default/main/vanilla scheme?
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.
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.
Jesus christ.
I'm sure there are great, rational reasons for this. What were they?
It's really interesting to think that the majority of our software platforms are A) Unix-derived and a bit of B) Windows, and both of those have pretty much taken over industry with Algol-derivatives (C, C++, Objective-C, Java...).
I mean, it's news when a company says "We don't use the above!"
With that in mind, it feels like Scheme is the like the Basques/Finns of the software world, a completely separate genealogical line that perdures to this day in small pockets here and there.
And you shouldn't think in terms of C, C++, etc being portable. There's lots of code written for GCC that doesn't conform to an explicit C++ standard (C++11/14 try to change this, but still). In the same way, you're really writing to the standard of language your C/C++ compiler implements. It's hairy, but the fact that things are not portable is just given more visibility in Scheme. Reasons for this are probably varied, but it also has to do with the variation in how Schemes are implemented at the lowest level (think Guile vs. CHICKEN, just in terms of GC they're worlds apart). At the end of the day, some code can be written to be portable (see some SRFIs) but we usually don't worry about minor inconsistencies within the larger Scheme community.
It's also why Chicken is
A) freaking AWESOME!!!
and B), totally sucks.
But that's a story for another day...
scheme originated in PL research (at the MIT AI lab) and was quickly pressed into service for education. As such, it has a strong userbase in academia. Those users need a language that was small, easy to implement, and powerful enough to express a wide variety of paradigms and concepts compactly. Meanwhile, Scheme users in the Real World, who want to Get Stuff Done, want that, but they also want things like OS interfaces, networking, module systems, FFIs, large standard libraries, etc. For many years, the approach the scheme standard took was to lay out the bare minimum required to be a scheme, and depend upon maintainers of various implementations to flesh it out. Furthermore, if the comitee couldn't agree on something, it went unspecified.
This resulted in something akin to the unix situation, but worse: we had a family of languages named Scheme, but all but the simplest programs would inevitably depend on implementation-specific language extensions, and all the implementations extended the language in different directions. Furthermore, the academics need Scheme to be easy to implement, so it was: it was so simple any easy that anyone could implement it, and anyone did, resulting in a bevy of Scheme implementations of varying levels of quality, from "industrial strength" to "weekend hack". There are admirable efforts to write cross implementation packages (most famously, SLIB), but it's generally not recomended, because it's a PITA to do.
R6RS tried to fix this, but... well, imagine that POSIX said, "we're trying to improve cross-system compatability, so you all have to implement Solaris Event Ports, Netlink, Streams, and the AIX sysadmin utilities to be considered POSIX. Just throw away whatever you were using instead of that."
Needless to say, this did not go over well.
R7RS tried to improve things by spliting the language into the traditional small core, and the larger stdlib, which you didn't have to implement to be scheme, but would hopefully improve interoperability between implementations. This seems to be working okay thus far, although the stdlib isn't done yet. We shall see...
Most Scheme implementations are cross-platform, and most issues you run into are the "extras" each implementation adds in.
Let me say this: most of my daily work involves programming in Scheme.
We investigated a lot of the top contenders, and ran into some rather random issues.
Gambit-C is damn fast. Its GC is amazing, and as the name implies, it cross-compiles to C. With a little tweaking, we got it running on some of the beefier Arduinos for some embedded work. Gambit includes custom namespaces for modules, which can make it easier to work with. However, documentation for Gambit is atrocious.
Guile doesn't support native compilation. You could compile down to the object code, and then write a C-wrapper for it, but it's painful working that way. (Also: Guile doesn't support the (void) function! They renamed it for no obvious reason.)
Chicken compiles down to native code, though its runtime is slightly slower than Gambit. It also implements a lot more SRFIs than Gambit, making it so you don't need to reinvent the wheel as much. However: the moment you add a package, Chicken can't compile statically anymore, and you need to build a distribution, and that gets rather hairy when you hit optional dependencies per platform.
All that being said, my work, for reasons I'm probably not able to explicitly go into, involves writing code that both Chicken and Gambit-C can run, and it isn't overly difficult, though I did have to reimplement some libraries that only one or the other had. Yet, in Scheme-land, that's half a days work.
Oh, by the way, as somebody who primarily uses Chicken, you forgot about the coolest part: Chicken is slower than Gambit, but it does Cheney on the MTA compilation, which means that call/cc is almost free. Given, there are some other tradeoffs, but it's still pretty cool.
Also, what kind of job are you in where you're writing Scheme code? That's totally awesome!
We had a dual Python/C stack, where we basically had a prototype in Python, running for small clients, and then a better C one for embedded devices.
We decided that was a bad idea, and went to rewrite the C for both consumer and embedded devices.
However, the lack of progress had the manager investigating all kinds of things, like MicroPython.
I had been playing around with Scheme in my spare time, and pointed out that Scheme was almost as fast as C, and almost as fast as Python for prototyping.
They handed me a test to see if Scheme was suitable -> Rewrite our Python prototype in Scheme, within three weeks.
Because of how consistent Scheme is, and how close Python's syntax is to it, it only took me three days.
With the decent C output of Gambit's compiler, I wrote a script that modified it to work on our embedded devices as well, in another three days.
The manager was sold, and our whole team moved to Scheme.
I was very unpopular for a few months.
As to the actual project? The little I can say, as it isn't launched yet, is that it's a kit designed for schools.
Cython.
We were trying to streamline two products into one:
* A C application that runs on an Arduino. * A Python application that runs on the desktop.
Cython may make the Python implementation faster, but it hardly solves the distribution issues. There's a reason MicroPython exists (and it was one of the contenders!)
Scheme became the product, because Scheme was easy to run on our hardware, and on consumer hardware. It was easy to develop with, fast to develop with, and runs faster than most high-level languages competing in this sphere.
Cython certainly has its use cases, and is a fantastic bit of software. But it didn't fit ours.
The use of call/cc i see in real programs i am aware of is green threads.
Don't forget larceny.
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.
https://groups.google.com/forum/#!topic/v8-users/kIVoA7GZAcY
[1] I am in no position to criticize anyone this way, and I wouldn't do it anyway.
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.
This attitude towards practicality, if you will, that runs rampant in scheme-land is one of the major barriers for adoption. If you look at Common Lisp, these issues do not exist, the end result being a multitude of substantial real-world projects across a variety of domains (commercial, opensource, academia, industry and so on).
The Guile maintainers very much care about usability.
guix package -i guile-emacsI 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.
Vim + paredit inside of tmux, with a proper REPL in another pane / window is a great workflow. Of course this requires some more plugins to Vim, but for the most part sending commands through tmux is pretty lightweight.
[0] https://bitbucket.org/kovisoft/slimv [1] http://www.nongnu.org/geiser/
When editing lisp in the original vi's Lisp mode, ( and ) operate over sexprs, { and } don't stop at atoms, moving you to the next sexpr, [[ and ]] skip to the next sexpr at top level, and if you set autoindent, your code is indented correctly for lisp.
Combined with vi's other operators, this is pretty good, although by no means as good as actual paredit.
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).
So yeah, it's not so much the Elisp in the Emacs source that's the problem, it's how do the maintainers switch to maintaining Elisp inside of the Guile project (up until now, Elisp was maintained as a language alongside Emacs). At the very least, this is how I understand it.
Yes, there is no way Emacs will get rid of elisp. That's why Guile Emacs includes writing an elisp frontend for Guile. (There is also a Frontend for ECMAScript and an experimental one for Lua)
Seems like it's not to far from being stable (if not perfect performance wise).