
GNU Guile 2.1.4 released - rekado
https://lists.gnu.org/archive/html/guile-devel/2016-09/msg00009.html
======
qwertyuiop924
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.

I love it, just not as much as I love Chicken.

~~~
na85
What is the scheme equivent of ANSI C or Common Lisp?

By that I mean what is the default/main/vanilla scheme?

~~~
qwertyuiop924
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.

~~~
AceJohnny2
> 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.

~~~
shakna
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.

~~~
qwertyuiop924
Neat. Yeah, it's a lot better than it used to be.

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!

~~~
shakna
Getting to use Scheme was almost an accident.

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.

~~~
alexkarbiv
>I was very unpopular for a few months.

Cython.

~~~
shakna
Cython simply wouldn't work.

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.

------
FlorianOver
I really admire Andy Wingo for all his great work. Thank you and the guile
team for the the outstanding results!

------
AceJohnny2
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 :(

~~~
shakna
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.

------
amirouche
This version of Guile makes possible better asynchronous code via
[https://github.com/wingo/fibers/wiki/Manual](https://github.com/wingo/fibers/wiki/Manual)
(which is the implementation of something similar to Python's async/await)

------
s_kilk
Anyone here know of any "real" programs and projects using Guile? Would be
curious to hear of any blazing success-stories.

~~~
amirouche
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.

~~~
davexunit
>There is no support for https, it's kind of a no-go if you want to access
REST APIs from Guile.

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.

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

~~~
davexunit
Not so fast, there is an open bug report to move HTTPS support into Guile
proper. The (non-trivial) work just needs to be done to make it happen.

The Guile maintainers very much care about usability.

------
rhabarba
Still waiting for Guile Emacs.

~~~
ThatGeoGuy
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.

[0]
[https://www.emacswiki.org/emacs/GuileEmacs](https://www.emacswiki.org/emacs/GuileEmacs)

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

~~~
ThatGeoGuy
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.

~~~
rhabarba
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?

------
Frenchgeek
[https://www.youtube.com/watch?v=Iof5pRAIZmw](https://www.youtube.com/watch?v=Iof5pRAIZmw)

( Sorry )

~~~
AceJohnny2
Well, you're not wrong: [http://knowyourmeme.com/memes/guiles-theme-goes-with-
everyth...](http://knowyourmeme.com/memes/guiles-theme-goes-with-everything)

