Thanks to the work of BT Templeton, Guile's Elisp implementation is now
fully Emacs-compatible, implementing all of Elisp's features and quirks
in the same way as the editor we know and love.
So where's my guile-based emacs build? Not holding my breath, but it certainly would be a very nice christmas present (not sure about the year though)!
(yeah, I know emacs is a lot more than just it's elisp implementation...)
Cool, so if/when the guile vm is default, does that mean we could finally get better process control in emacs?
Honestly I love emacs but it is not the most performant thing on the planet. Redrawing taking tons of time bugs that have existed for years, non blocking i/o to things like processes doesn't really exist etc...
It could do for a lot of spit and polish in the concurrency/threading land.
It's still in an early stage, but it works. That emacswiki post points you in the right direction, but if you use the Guix package manager, you can give it a try: "guix package -i guile-emacs"
Mostly at this point it needs people working on it and playing around with it. Considering you're fairly excited about it, maybe you should give it a spin? :)
Couldn't they have picked a better name for these modules? seems like it would be quite obnoxious to remember all these by their number instead of a nice name.
They may want to alias these to memorable names, like 'sfri-time', for this one. There are probably drawbacks to using such a scheme, though, like possible ambiguities if two SFRIs cover the same topic differently.
As others have said, this has to do with the numbering system for Scheme Requests For Implementation at <http://srfi.schemers.org/>, but I agree that more memorable module names like (date) would be useful for commonly used SRFIs.
On the subject of SRFIs, which ones do you fellow Schemers use? I think the ones I use most often are SRFI-1, SRFI-9, SRFI-11, SRFI-26, SRFI-37, and SRFI-41.
I think some sort of alias would be good. Perhaps it could implemented as a module that just re-exports all of the public symbols from the relevant SRFI module. Needs discussion on guile-devel.
the website looks great. But it's always so confusing that GNU's language of choice doesn't seem to be used by anyone. The marquee projects listed as using guile seemed a little underwhelming
its a flavor of scheme. But it was made to be the language of extension in GNU projects. I've just never heard of anyone actually using it. And the projects that seemed to have embraced it seem rather small for the banner or marquee projects on their website.
There's also Lilypond (lots of Guile) and Gimp (a little bit of Guile), which are both pretty well-known projects. Guix itself is a large project. GDB has Guile scripting support as well.
There are also gdb and make, which are probably a bit more prominent examples of guile-integration. Perhaps one day, emacs will do so as well.
I've embedded Guile into some of my own projects, and it's a great and fun way to bring a bit of life in "dead" compiled code. Many more projects would benefit from this.
It had some kind of BSD moment IIRC. Just when it was supposed to catch on, something pulled the rug and it was set back a decade. Slowly coming back to light I guess.
I agree, but I'm also a bit (selfishly) sad to see that the old logos have disappeared (I was the one who redraw them in SVG, before only bitmap formats where available).
Awesome. I worked on Guile almost exactly 20 years ago. It's probably very different from what it looked like back then. Emacs-on-Guile was one of Stallman's ideas back then, as well as using it for a GNU tcl implementation. Sounds like we're half way there!
Not that I know of, but Racket and Chicken, and I believe newer versions of Gambit, can produce executable from their version of scheme. Scheme was originally meant to be embedded so compiling to an standalone executable was never part of its goals.
The 'website' is really just Jeff Siskind's page with a listing of what he's done.
It seems mostly dead nowadays and there's very little info to find on it. The following page is pretty much the most amount of actual information I could find:
Keep in mind that Stalin is a very small subset of R4RS (note that the current is R7RS-small), and in many ways becomes a very small portion of an already small language. This makes it easy to optimize, but can be annoying if you're coming from other languages that are less spartan.
As for using Stalin, I would argue that nowadays it is better to use the CHICKEN port of Stalin [1], as it is a bit more up-to-date and provides some extensions (such as using '\n' in string literals, something Stalin didn't provide from the outset!!!). In any case, it's nice to see the variety in Scheme implementations, but in the case of Stalin I personally turn my nose up, as CHICKEN is often fast enough on it's own (or can be made to be), without restricting myself to a very tiny set of tools and libraries. That's not to say the work on Stalin hasn't been appreciated, I'm sure Gambit and CHICKEN have taken their fair share of ideas from Stalin as time has gone on.
Guile is designed to be an embedded language, so in theory you could write a small C wrapper to set up the Guile environment and load your scheme program... I'm not sure if libguile can be statically though
The VM written in C that runs the bytecode actually relatively small... most of Guile, including the interpreter and the compilers, are written in Guile itself and run on top of the VM. Those components are compiled object files... they use the ELF format but are not actually executables. IIRC code is loaded by memory mapping the files and Guile has its own way of linking them. I supposed that embedding these files into an executable would require a different mechanism of linking which I am not sure exists. Maybe it does, I just haven't dug that far down into it. The compiler and interpreter take forever to compile BTW... it is definitely preferable to just get Guile from your distro if you can.
36 comments
[ 3.2 ms ] story [ 104 ms ] threadComplete Emacs-compatible Elisp implementation
Thanks to the work of BT Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love.
So where's my guile-based emacs build? Not holding my breath, but it certainly would be a very nice christmas present (not sure about the year though)!
(yeah, I know emacs is a lot more than just it's elisp implementation...)
Honestly I love emacs but it is not the most performant thing on the planet. Redrawing taking tons of time bugs that have existed for years, non blocking i/o to things like processes doesn't really exist etc...
It could do for a lot of spit and polish in the concurrency/threading land.
It's still in an early stage, but it works. That emacswiki post points you in the right direction, but if you use the Guix package manager, you can give it a try: "guix package -i guile-emacs"
Mostly at this point it needs people working on it and playing around with it. Considering you're fairly excited about it, maybe you should give it a spin? :)
BTW, what's this 2.1.1 vs 2.2 thing? I see they are used interchangeably.
Gnome does this as well - 3.17.x was beta, 3.18.x stable.
Linux was one of the first projects to use this pattern, but hasn't since early 2.6.x.
> (use-modules (srfi srfi-19))
Couldn't they have picked a better name for these modules? seems like it would be quite obnoxious to remember all these by their number instead of a nice name.
SRFIs (Scheme Requests for Implementation) are something like RFC's for the Scheme language.
They are proposed features that are not standardized in the Scheme Report. Their numbers identify the proposal.
So if we see srfi-19 being referenced in Guile code, it is cryptic, but it references the proposal which gives the requirements for that feature.
If you're porting code from Guile which depends on srfi-19 to another Scheme, the consistency of the reference will make it easy.
They may want to alias these to memorable names, like 'sfri-time', for this one. There are probably drawbacks to using such a scheme, though, like possible ambiguities if two SFRIs cover the same topic differently.
On the subject of SRFIs, which ones do you fellow Schemers use? I think the ones I use most often are SRFI-1, SRFI-9, SRFI-11, SRFI-26, SRFI-37, and SRFI-41.
...sounds like a good candidate for an SRFI...
The website could feature a few more projects.
I've embedded Guile into some of my own projects, and it's a great and fun way to bring a bit of life in "dead" compiled code. Many more projects would benefit from this.
2016 will be the year of Guile on GNU/Hurd.
http://racket-lang.org/
http://www.call-cc.org/
http://gambitscheme.org/wiki/index.php/Main_Page
The 'website' is really just Jeff Siskind's page with a listing of what he's done.
It seems mostly dead nowadays and there's very little info to find on it. The following page is pretty much the most amount of actual information I could find:
http://community.schemewiki.org/?Stalin
As for using Stalin, I would argue that nowadays it is better to use the CHICKEN port of Stalin [1], as it is a bit more up-to-date and provides some extensions (such as using '\n' in string literals, something Stalin didn't provide from the outset!!!). In any case, it's nice to see the variety in Scheme implementations, but in the case of Stalin I personally turn my nose up, as CHICKEN is often fast enough on it's own (or can be made to be), without restricting myself to a very tiny set of tools and libraries. That's not to say the work on Stalin hasn't been appreciated, I'm sure Gambit and CHICKEN have taken their fair share of ideas from Stalin as time has gone on.
[1] http://wiki.call-cc.org/eggref/4/stalin
The VM written in C that runs the bytecode actually relatively small... most of Guile, including the interpreter and the compilers, are written in Guile itself and run on top of the VM. Those components are compiled object files... they use the ELF format but are not actually executables. IIRC code is loaded by memory mapping the files and Guile has its own way of linking them. I supposed that embedding these files into an executable would require a different mechanism of linking which I am not sure exists. Maybe it does, I just haven't dug that far down into it. The compiler and interpreter take forever to compile BTW... it is definitely preferable to just get Guile from your distro if you can.