GNU Guile 2.1.1 released | Hacker News Reader

GNU Guile 2.1.1 released

lists.gnu.org

174 pointsdavexunit36 comments

From the announcement:

Complete 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...)

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.

How much of that is limited by the C core as well? Waiting for that to be fixed seems like another level of infinity than guile-emacs.

So yeah, Guile-powered Emacs exists! http://www.emacswiki.org/emacs/GuileEmacs

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? :)

I wonder how guile-elisp would fare on benchmarks...

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!

Some old GNU ideas are popping again. Guile as a system language in GuixSD. Hurd too. Funny times.

Considering the speed of development of some of FSF's project, it may not be that much different than what you remember 20 years ago ;)

The new website looks much better than before, great job. I am planning to build something using Guile, but sadly my time is limited.

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).

Right. It looks cute.

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

It is a Scheme implementation. At very least many universities do use Scheme.

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.

The website could feature a few more projects.

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 was chosen as the language of the GNU project in the mid 1980's. It's just taken a while to gain adoption. :-)

2016 will be the year of Guile on GNU/Hurd.

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.

nice website! for some people this makes a huge a difference.

BTW, what's this 2.1.1 vs 2.2 thing? I see they are used interchangeably.

This is the not-entirely-unique practice of using odd minor numbers for beta releases and even minor numbers for stable releases.

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.

Guile compiles to bytecode, is there a way to then link that to guile to create a standalone executable?

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.

http://racket-lang.org/

http://www.call-cc.org/

http://gambitscheme.org/wiki/index.php/Main_Page

There's also Stalin, an extremely optimization-heavy compiler for Scheme to C; https://engineering.purdue.edu/~qobi/software.html

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

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.

[1] http://wiki.call-cc.org/eggref/4/stalin

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.

First time looking at Guile and I see this:

> (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.

The SRFI numbering is Scheme-language-wide; it's not a Guile thing.

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.

That makes a little more sense. Thanks!

srfi is how scheme does things however. Virtually every other scheme interpreter that supports these modules have the same naming scheme.

It refers to the SRFI process and proposals (http://srfi.schemers.org/srfi-process.html), specifically: http://srfi.schemers.org/srfi-19/srfi-19.html

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.

Weren't aliases proposed ? what would you think ? The SRFI system is not user friendly. It feels like typing binary cpu opcode.

>Weren't aliases proposed?

...sounds like a good candidate for an SRFI...

SRFI-927 I guess

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.

Somehow similar to meta packages in linux distributions ? pragmatic.

Reply on news.ycombinator.com