Two Years of GNU Guile Scheme 2.0

Two years ago Guile Scheme, the official extension language of the GNU project, released version 2.0, a major upgrade to the implementation. As part of the two year anniversary, the maintainers organized a challenge to hack a small project using Guile in 30 days as part of a birthday software potluck. The two coolest dishes appear to be OpenGL support using the FFI, and XCB bindings built using the XML specification for XCB: "guile-xcb is a language implemented in the Guile VM that parses the XML files used by the xcb project to specify the X protocol and compiles them into Guile modules containing all the methods and data needed to send requests to the X server and receive replies/events back. If new X extensions are added to the xcb library, guile-xcb can compile and add them with no additional work. " See the release announcement for details on the other dishes.

Comments

Guile supports curly-infix, too!

[dwheeler]

Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions", as developed by the Readable Lisp S-expressions Project. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.

Re:Guile supports curly-infix, too!

[Anonymous Coward]

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list? In (+ a b) it's clear to both user and interpreter what the first member of the list is, but with {a + b} the interpreter may know what is what, but the user no longer sees firsthand that the s-expression is a list like any other. The key to groking Lisp is to learn to think recursively like the interpreter, and I would think that this change in notation unhealthily forces thinking patterns derived from other languages.

Re:Guile supports curly-infix, too!

[cduffy]

Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list?

Plenty of LISPs break that "rule", and usually for the better. Clojure wouldn't be the tremendously practical and useful language it is if it didn't have vectors, maps, queues, and the like.

What's important is that the language retains isomorphism (and thus, LISP's full measure of metaprogramming power) -- as long as your parse tree and your code map 1:1, adding some additional types does no harm and a world of good.

Re:Guile supports curly-infix, too!

[larry bagina]

You should read John McCarthy's original lisp paper sometime. He used m(eta)-expressions -- eg, +[a, b] -- rather than s-expressions. S-expression evaluation was implemented first and now you're stuck with it.

Re:Guile supports curly-infix, too!

[rmstar]

For Common Lisp there is the "infix" package, which you can just load as part of your program. You can write infix using a #i() reader macro. Thus, #i(1+1) is equivalent to (+ 1 1), etc.

Programmers that use Lisp or Scheme for a while end up using plain prefix. The percieved inconvenience of prefix notation is due to not being used to it. After a while you realize that prefix notation is a lot more readable and less error-prone than infix.

Emacs and Guile need each other

[Anonymous Coward]

I've wanted to get into Lisp, but it's frustrating that my everyday GNU environment is split between Guile and Emacs Lisp. I wish that the project, talked about for years, to rewrite Emacs and base it on Guile would take off. It would save Guile, in a sense, because in spite of Scheme's status as the official GNU extension language it tends to be overlooked, and Emacs would benefit greatly from the bindings already developed for Guile.

Re:Emacs and Guile need each other

[Unknown Lamer]

It's close to being reality. Guile has an Emacs-Lisp compiler to its VM that can run actual elisp programs, but lacks... the emacs part. And last summer's GSoC (perhaps this summer, finishing it?) saw emacs's lisp interpreter ported to guile... as in, the C representations of Emacs's internal data types and control structures are done using libguile. The code is currently being rebased on the latest emacs trunk; hopefully it'll see public release sooner than later.

Now the two pieces just have to meet in the middle.

So that's the first 95%. Now just for the other 95%!

Scheme rocks, but lost the race

[WaywardGeek]

I love Scheme. I even wrote my own scheme interpreter way back and used it as the embedded control language in QuickLogic's P&R tools. However, only software geeks like Scheme, making it a terrible language for tool control for anything but software dev tools. TCL beat the heck out of Scheme in terms of popularity for this purpose. Python beat the heck out of Scheme as well. Perl got adopted by the text mashing crowd. Also, Guile, at least in the 1.0 version had issues. For example, it really wanted to have main in it's code, while your entire application was something it called. TCL has a better architecture for embedding. Anyway, this is nice, but I don't personally see a significant future for Scheme.

Re:Scheme rocks, but lost the race

[WaywardGeek]

Huh? Here's Python's lambda expressions. And of course, from the fountain of all knowledge, Python has first class functions. Now, that said, it's still not Scheme.

Re:scheme, bitches!

[Anonymous Coward]

Perl is dead

Only in my happiest, wildest, wettest dreams.

Curly-infix-expressions are just abbreviations

[dwheeler]

Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations. In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c). We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ for more info, and in particular, please join the mailing list!!

Re:Scheme looks scary and unreadable to me

[TheLink]

Once you get used to it, Scheme (or any other modern Lisp) is a very easy language to write clean, effective code in.

Scheme is great but the problem is I'm a crap programmer. So a language that helps with the code I write is not as important as a language that helps because of all the code that I DON'T have to write.

Basically I prefer to pick a language where there are already tons of existing good libraries/modules/code I can _easily_ use to do what I want. Stuff written by better programmers than me. That way the effective quality of my program goes up - since much of the functionality/code is actually written by someone else.

The other great thing is I don't normally have to support, document and fix that 3rd party code that I didn't write. ;)

Languages like scheme are great if most of the stuff you need to get done is stuff that is unlike anything else someone else has written. But for most of us that's not true.

Spaces vs. tabs

[dwheeler]

There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.