As someone who has merely dabbled lightly with Scheme, what's the main issue with Guile?
Looking on the outside it looks like its a decent Scheme and the problem is lack of use and adoption (like in Emacs). Is that a correct assessment, or is the lack of adoption caused by issues with the implementation itself?
Or am I just all wrong about the state of Guile itself, and it's quite widely adopted, just that nobody speaks too much about it?
Earlier someone posted in response to my comments about Guile a cool FRP system for 2D game design in Guile. There are also seem not projects using Guile, from what I can tell. Check out the list at Guile's GNU project page.
That being said, most languages need some form of dependency management, and this story has yet to see an ending in Guile. People continue work on one called Guildhall, but it is not yet complete.
I tried deploying on my Arch Linux laptop, and encountered some issues. I also thought it would be cool to try Guile and GNOME for quick apps, but without dependency managers and incomplete documentation, it is hard for me as I am, if I can toot my own horn, a low-intermediate Linux user and a very novice Scheme student.
So long story short: toolchain and documentation are not there yet. I continue to hope because it is still cool.
Also, check this blog. I and others mentioned it. It is very cool and gives you very deep technical insight from a Guile maintainer into all the hard work being put into its core improvements.
Dependency management for Guile will be best handled via Guix - which handles not only Guile specific dependencies, but can replace the system package manager entirely, and perhaps parts of the crufty gnu build system too, now that you can define custom build processes in guix packages, and you can also use guile from GNU Make. Guix will also be used for configuration management too (since configurations are treated like packages.)
Guix is really the killer app that will push Guile forwards, and towards realizing Guile for it was originally meant to be - an extension language for the GNU system. DMD is also being developed in Guile as part of the GNU system - to allow for dependency based daemon initialization without completely invading your system like certain others.
I don't see Guile as a candidate for merely "tacking onto" existing apps like you typically do with Lua, but as more of an integrated part of a dynamically configurable operating system, much like emacs but for the whole system.
I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating.
Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away.
This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug.
You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several).
It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix.
The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands.
It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store.
For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
>In short, it is no Lua (or really Lua+LuaJIT), but it might be there one day.
Lua and Guile have different use cases. Typically, Lua is embedded in an application. With Guile, you can still embed, but it's not really the best way to do things. It's much better to write your application as a shared library that Guile can load and thus extend Guile. Even better is to write your application in pure Guile, using the C FFI when needed.
Fair, but I have been under the impression that the intended use case of Guile is an embedded extension language, like how you describe Lua, and like the language is was intended to replace, Emacs Lisp.
"Guile is an efficient virtual machine that executes a portable instruction set generated by its optimizing compiler, and integrates very easily with C and C++ application code. In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway), which means your application can be extended in the language (or languages) most appropriate for your user base. And Guile's tools for parsing and compiling are exposed as part of its standard module set, so support for additional languages can be added without writing a single line of C."
The main issue with Guile is the same issue as with any other Scheme, and that issue is that it is a Scheme. No single Scheme is widely adopted and the main reason for that is extreme balkanization. You dont write code in Scheme, you write Guile, Racket, Chicken, etc.
The Scheme philosophy, which was developed in opposition to batteries-included aka "bloated" Common Lisp, was to have a small core and emphasize simplicity, purity, etc. For years proponents of Scheme have emphasized how beautiful and simple the small standard of 50 pages is, compared with Common Lisps "bloated" 1000+ pages standard.
This had two consequences:
1. It was extremely easy to write a scheme implementation, soinstead of writing code _in_ scheme, people wrote _schemes_. Hundreds of them. And while other people spent the last 20 years writing thousands of useful libraries in C, python, java, scheme implementors spent reinventing the wheel, over and over and over and over again. Today there are more implementations of scheme than libraries in scheme.
2. The emphasis on "small core" might be cute for teaching SICP, but in order to be able to do anything useful with the implementation, it forced the implementors to reinvent the wheels for everything else. And each implementation did it their own way because standardization was considered "selling out" and aping the nemesis Common Lisp. This led to _extreme_ code unportability.
Nowadays they are somehow trying to standardize, but with the consequence that they are realizing that by doing that, they are becoming indistinguishable from their old nemesis Common Lisp, which went through the same balkanization phase 20 years ago, so the point of splitting off Scheme from Lisp is becoming questionable. Instead of wasting precious time writing 1001 scheme implementations, they could have spent the last 20 years writing useful common lisp libraries and competing with other batteries-included languages like java and python.
In short: Besides the social problems that every Scheme suffers from and the Lisp world suffered during the 80s, Guile on its own is doing quite well. Once it is integrated into Emacs, Emacs will become Guile's killer app, boost its popularity and set it apart from other schemes.
I concur, with sorrow. Scheme is such a nice language... I believe a standardised syntax to define compound data structures (aka defstruct) and a standardised C FFI would make Scheme language usable. If these existed, I'd implement a Leiningen-ish tool and a couple libraries for Scheme, to get going with web development.
(There is one more problem I have with Scheme, which is the name. It sounds identical to a vulgar Turkish word for "my penis"; resulting in awkward situations when talking about the language in Turkey, where I live. :))
I can only call it Lisp in public. Otherwise, Turkish translation of "I'm using Scheme to build this application" sounds identical to "I'm using my penis to build this application". I said the sentence at lunch in my last job, and boy, albeit we're all devs, it was awkward.
The Turkish word? Sure, it is spelled as sikim, where sik [1] is the (quite vulgar) word for penis (noun, when used as verb, means to f.ck), and (i)m is the possessive affix [2]. The letter i is always pronounced like the first i in victim, and the word is pronounced like si-kim. The perception of the phrase is similar to that of my cock, rather than my penis.
One might think that the similarity is so vague, that wouldn't pose a problem to speak it out loud. I, personally never recognised the similarity, until I spoke the word out loud.
Sk-eme, as in school, or scam, not as in schweppes, or Schrödinger. I'm not a native speaker, yet quite practised. And Sk-eme is how most pronounce the name, as far as I've seen. You can't know how much I wish it was called plan, plot or something :)
We need a web-service that checks any word for any similarities to obscene words in languages of the worlds! Though I suspect that a lot of words may be such words.
Additionally, the licensing is perhaps not quite as worry-free as something like Tcl's or Lua's. Guile is LGPL, which means you should be able to link it in without problems, but the subtleties of GPL vs LGPL are probably lost on many people, who steer clear of the whole lot.
Also, at least IIRC, at one point in time you could "check in, but never leave" to hotel Guile from C code. Once you called the Guile function, you pretty much handed off control. Or something like that, my memory is a bit fuzzy.
So embedding Guile in something like Apache was tricky. IIRC, this is done so that Guile can GC stuff on the C stack by walking backwards and examining it.
Woops, you're right. That was what I bumped into at the time and searched on the "problematic" function. Looks like things have indeed improved from that point of view:
We are truly sorry that you cannot use our free software to build proprietary software. Guile is a GNU project, thus it shares the mission of creating a fully free operating system.
> Once it is integrated into Emacs, Emacs will become Guile's killer app, boost its popularity and set it apart from other schemes.
You say that like Guile becoming the Emacs Lisp runtime is a foregone conclusion. It's not. The Emacs Lisp interpreter is so tightly bound to the C core (which uses lisp primitives for error handling, memory allocation, and data storage) that ripping it would involve massive modifications to large parts of that core.
Even if Guile were included in Emacs, it would be running Emacs Lisp almost all the time, not Scheme. Elisp, being a Lisp-2, is much closer to Common Lisp than it is to Scheme, and the recent integration of the cl-lib package has brought it even closer. We even have a CLOS workalike.
Embedding Guile in Emacs is a waste of time and energy. There are many desperately needed features in Emacs, and implementing them isn't going to be any easier after rebasing the runtime. No, being able to write code in JavaScript or Scheme isn't going to make things easier. It'll make things harder due to language fragmentation and impedance mismatches between the various languages.
The idea isn't to write Emacs extensions in Scheme instead of Elisp, but to give Elisp a much more powerful environment in which to run. The Guile VM brings features such as delimited continuations, threading, and a C FFI that Emacs could benefit greatly from.
A lot of good patches in this release. I'm glad that Guile finally ships the SRFI-64 testing API and the SRFI-111 boxes API.
I am the co-author of the cooperative REPL servers patch. This patch allows an interactive programming environment to be integrated into applications that are single-threaded and/or run an event loop. I am using cooperative REPLs for a 2D game development engine written in pure Guile.
I highly recommend trying out Guile. The community is really great. I entered #guile on freenode about a year ago when I knew nothing about Scheme and everyone was friendly and helpful. I've since authored 3 patches and written some pretty awesome programs with Guile.
To further entice you to give Guile a try, check out this post/screencast in which I demonstrate functional reactive programming in the context of game development:
What's up with Scheme naming packages "SRFI-some-number" instead of a memorizable and meaningful name like every other language? It's one of the things I find the most frustrating about Scheme.
It's not quite right to think of SRFI's as libraries, because they are specifications. They are numbered for the same reason why RFCs and other types of specifications are numbered. In addition to their number, they also have names. For example, SRFI-41 is named "Streams". SRFIs are API specifications with potentially many implementations. Each Scheme implementation may implement a SRFI a bit differently.
Talking about Guile specifically, there are a bunch of libraries with "memorizable and meaningful names". guile-sdl, guile-json, guile-2d, guile-compost, guile-ssh, guile-xcb, etc.
Guile is a great little Scheme. I found it to be a very welcoming environment to program on Linux and I'm having a ton of fun relearning Lisp with it. Having tried using SBCL as a "Unix-ing with Lisp", Guile was so much easier. It Just Worked the way I expected when touching the OS, compared to CL's crazy filepaths and time epoch.
I've also greatly enjoyed reading the compiler/VM backstory on http://wingolog.org/ . It occurs to me that if you have an efficient Scheme VM, you could use it as a target for a lot of other languages and get something of an 100% OSS .Net or Java polyglot ecosystem going. Parrot was the previous hope but it seems to have fallen into being a mostly academic exercise.
And then there's "GuileMacs", which seems to get closer to a reality with every push. Not being a native Lisper, I think Emacs could use a boost from having a faster VM and lexical scope.
Really there's just a lot to love about Guile. I'm excited about all the activity and attention it's getting.
Not quite. lexical-binding is buffer-local, so evaling that code probably won't do what you want. Instead, put this at the top of any elisp file you want to be interpreted with lexical scoping:
;; -*- lexical-binding: t -*-
Unfortunately, lexical-binding _must_ be optional and off by default. Old code often breaks badly when run under the new rules, mostly because people did silly things like sending out-parameters by symbol name and using add-to-list on local variables.
I'm hopeful for Rubinius w/r/t a long-term viable polyglot VM. It has _lots_ of languages built for it but Ruby is still its most popular and mature as far as I know.
I wasn't aware Rubinius was a polygot vm -- but are there any usable languages ported other than Ruby? Both the Smalltalk and Python port appear to be unfinished and abandoned?
44 comments
[ 1.6 ms ] story [ 96.6 ms ] threadLooking on the outside it looks like its a decent Scheme and the problem is lack of use and adoption (like in Emacs). Is that a correct assessment, or is the lack of adoption caused by issues with the implementation itself?
Or am I just all wrong about the state of Guile itself, and it's quite widely adopted, just that nobody speaks too much about it?
https://www.gnu.org/software/guile/gnu-guile-projects.html
That being said, most languages need some form of dependency management, and this story has yet to see an ending in Guile. People continue work on one called Guildhall, but it is not yet complete.
http://wingolog.org/archives/2011/07/04/guile-2-0-2-building...
I tried deploying on my Arch Linux laptop, and encountered some issues. I also thought it would be cool to try Guile and GNOME for quick apps, but without dependency managers and incomplete documentation, it is hard for me as I am, if I can toot my own horn, a low-intermediate Linux user and a very novice Scheme student.
So long story short: toolchain and documentation are not there yet. I continue to hope because it is still cool.
Also, check this blog. I and others mentioned it. It is very cool and gives you very deep technical insight from a Guile maintainer into all the hard work being put into its core improvements.
http://wingolog.org/
In short, it is no Lua (or really Lua+LuaJIT), but it might be there one day.
Guix is really the killer app that will push Guile forwards, and towards realizing Guile for it was originally meant to be - an extension language for the GNU system. DMD is also being developed in Guile as part of the GNU system - to allow for dependency based daemon initialization without completely invading your system like certain others.
I don't see Guile as a candidate for merely "tacking onto" existing apps like you typically do with Lua, but as more of an integrated part of a dynamically configurable operating system, much like emacs but for the whole system.
Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away.
This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug.
http://nixos.org/nixos/screenshots/nixos-terminals.png
It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix.
The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands.
It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store.
For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
Lua and Guile have different use cases. Typically, Lua is embedded in an application. With Guile, you can still embed, but it's not really the best way to do things. It's much better to write your application as a shared library that Guile can load and thus extend Guile. Even better is to write your application in pure Guile, using the C FFI when needed.
From the website (http://gnu.org/s/guile):
"Guile is an efficient virtual machine that executes a portable instruction set generated by its optimizing compiler, and integrates very easily with C and C++ application code. In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway), which means your application can be extended in the language (or languages) most appropriate for your user base. And Guile's tools for parsing and compiling are exposed as part of its standard module set, so support for additional languages can be added without writing a single line of C."
That's how I usually use Lua.
The Scheme philosophy, which was developed in opposition to batteries-included aka "bloated" Common Lisp, was to have a small core and emphasize simplicity, purity, etc. For years proponents of Scheme have emphasized how beautiful and simple the small standard of 50 pages is, compared with Common Lisps "bloated" 1000+ pages standard.
This had two consequences:
1. It was extremely easy to write a scheme implementation, soinstead of writing code _in_ scheme, people wrote _schemes_. Hundreds of them. And while other people spent the last 20 years writing thousands of useful libraries in C, python, java, scheme implementors spent reinventing the wheel, over and over and over and over again. Today there are more implementations of scheme than libraries in scheme.
2. The emphasis on "small core" might be cute for teaching SICP, but in order to be able to do anything useful with the implementation, it forced the implementors to reinvent the wheels for everything else. And each implementation did it their own way because standardization was considered "selling out" and aping the nemesis Common Lisp. This led to _extreme_ code unportability.
Nowadays they are somehow trying to standardize, but with the consequence that they are realizing that by doing that, they are becoming indistinguishable from their old nemesis Common Lisp, which went through the same balkanization phase 20 years ago, so the point of splitting off Scheme from Lisp is becoming questionable. Instead of wasting precious time writing 1001 scheme implementations, they could have spent the last 20 years writing useful common lisp libraries and competing with other batteries-included languages like java and python.
In short: Besides the social problems that every Scheme suffers from and the Lisp world suffered during the 80s, Guile on its own is doing quite well. Once it is integrated into Emacs, Emacs will become Guile's killer app, boost its popularity and set it apart from other schemes.
(There is one more problem I have with Scheme, which is the name. It sounds identical to a vulgar Turkish word for "my penis"; resulting in awkward situations when talking about the language in Turkey, where I live. :))
edit:
One might think that the similarity is so vague, that wouldn't pose a problem to speak it out loud. I, personally never recognised the similarity, until I spoke the word out loud.
[1] http://www.turkishdictionary.net/?word=sik
[2] Turkish is slightly similar to Latin.
edit: add a newline between footnotes
Do you say Sch-eme or Sk-eme? I think both are ok, but please correct me if you are a native english speaker.
Click the speaker button on the bottom left of the text box to listen:
http://translate.google.com/#en/fr/scheme http://translate.google.com/#tr/fr/sikim
They have distinctly different pronunciations.
Isn't this what SFRI 9 is?
http://srfi.schemers.org/srfi-9/srfi-9.html
Also, at least IIRC, at one point in time you could "check in, but never leave" to hotel Guile from C code. Once you called the Guile function, you pretty much handed off control. Or something like that, my memory is a bit fuzzy.
Here we go:
https://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/S...
So embedding Guile in something like Apache was tricky. IIRC, this is done so that Guile can GC stuff on the C stack by walking backwards and examining it.
(Edit is -> was)
http://www.gnu.org/software/guile/manual/html_node/Guile-Ini...
If the culture is to GPL lots of libraries and projects, well that scares me away.
You say that like Guile becoming the Emacs Lisp runtime is a foregone conclusion. It's not. The Emacs Lisp interpreter is so tightly bound to the C core (which uses lisp primitives for error handling, memory allocation, and data storage) that ripping it would involve massive modifications to large parts of that core.
Even if Guile were included in Emacs, it would be running Emacs Lisp almost all the time, not Scheme. Elisp, being a Lisp-2, is much closer to Common Lisp than it is to Scheme, and the recent integration of the cl-lib package has brought it even closer. We even have a CLOS workalike.
Embedding Guile in Emacs is a waste of time and energy. There are many desperately needed features in Emacs, and implementing them isn't going to be any easier after rebasing the runtime. No, being able to write code in JavaScript or Scheme isn't going to make things easier. It'll make things harder due to language fragmentation and impedance mismatches between the various languages.
I am the co-author of the cooperative REPL servers patch. This patch allows an interactive programming environment to be integrated into applications that are single-threaded and/or run an event loop. I am using cooperative REPLs for a 2D game development engine written in pure Guile.
I highly recommend trying out Guile. The community is really great. I entered #guile on freenode about a year ago when I knew nothing about Scheme and everyone was friendly and helpful. I've since authored 3 patches and written some pretty awesome programs with Guile.
To further entice you to give Guile a try, check out this post/screencast in which I demonstrate functional reactive programming in the context of game development:
http://dthompson.us/functional-reactive-programming-in-schem...
Happy hacking!
Talking about Guile specifically, there are a bunch of libraries with "memorizable and meaningful names". guile-sdl, guile-json, guile-2d, guile-compost, guile-ssh, guile-xcb, etc.
SFRI = Scheme Requests for Implementation
I've also greatly enjoyed reading the compiler/VM backstory on http://wingolog.org/ . It occurs to me that if you have an efficient Scheme VM, you could use it as a target for a lot of other languages and get something of an 100% OSS .Net or Java polyglot ecosystem going. Parrot was the previous hope but it seems to have fallen into being a mostly academic exercise.
And then there's "GuileMacs", which seems to get closer to a reality with every push. Not being a native Lisper, I think Emacs could use a boost from having a faster VM and lexical scope.
Really there's just a lot to love about Guile. I'm excited about all the activity and attention it's getting.
http://rubini.us/
[0] https://github.com/bakkdoor/fancy