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.
Not sure what fancy logic you have in mind. It's a package manager so I have it build packages for me. I also use 'guix environment' as an RVM/Bundler replacement. Guix "just" builds the packages for me, but I am able to package things with much greater speed than with traditional package managers and the resulting binaries are bit-reproducible.
The project required writing plenty of Scheme code to describe the package recipes. A very non-trivial amount. Why are you so adamant to dismiss what I've done?
It's both non negative[1] and non personal, just an intellectual distinction to avoid giving credit to the wrong object: a language or a tool written in this language. Hoping you're not offended anymore.
[1] I am in no position to criticize anyone this way, and I wouldn't do it anyway.
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.
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'.
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.
It is preposterous to expect people to write their own HTTPS support on top of something as primitive as GnuTLS!
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).
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)
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.
I actually do not know, as I tend to use slimv [0]. There's a lot of buzz lately around geiser [1] for Emacs, and few Scheme implementations provide a workable SLIME interface, but for the most part I get by. I don't miss too much, and don't see why everyone assumes Emacs is the only way to write lispy code (without a full blown IDE like Dr. Racket).
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.
Thing is, Emacs beat vim at extensibility, and vim's been playing catchup in that area ever since. Also, geiser is really, really good.
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.
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).
This is probably the main misconception: Guile is only included to change the underlying Elisp implementation, not to completely change everything from Elisp to Scheme. The problem is mostly getting maintainers to switch over (as most are old enough to have dabbled in the current Elisp engine at least a few times, if not helped write the original implementation).
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.
There are large packages like Gnus and TRAMP which are directly developed inside (and distributed with) Emacs, but, in theory, they should "just work" in the Guile version even after XEmacs support was dropped, right?
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)
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.
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.
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.
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.
> Writing portable scheme is almost impossible, and frowned upon.
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.
Do keep in mind portable here is with regards to "between implementations" and not "per platform." Code between PyPy and CPython isn't guaranteed to be 100% portable (although they try), and in Scheme it's much the same way.
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.
By nonportable, I assume you mean "between implementations", because that's where the nonportability is. And yes, there is. It has to do with scheme's origin.
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...
Portability between implementations is a nightmare, and you end up adopting only one. Its not overly different than the compatibility problems you hit between JPython, CPython, and IronPython.
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.
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.
...mostly because it's so expensive. But you can use call/cc for all kinds of things: exceptions, python-style generator functions, delimited continuations, and famously, webservers.
> 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.
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.
67 comments
[ 0.16 ms ] story [ 142 ms ] threadhttps://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.
[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.
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).
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.
( Sorry )
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.