The future of Emacs, Guile, and Emacs Lisp

I think this is wrong. As far as I know, all Elisp functions (whether C subrs or Elisp defuns), including the string API, are Guile procedure objects in Guile-Emacs, just as Scheme procedures are. And Elisp strings are just one other data type aside Scheme strings. So working with Elisp strings in Guile-Emacs just means that the Guile VM applies procedures that are Elisp functions to objects that are Elisp strings; no encoding or decoding is involved.

(It could be that the Scheme string type gets benefits from being a native type or so, but I don't think that makes much of a difference either.)

IFF however you want to pass Elisp strings to a Scheme API (which naturally expects Scheme strings, not Elisp strings), you need to convert. Monnier's concern about Scheme errors getting caught by Emacs's interactive debugger comes into consideration here; indeed if you cause some error in the current (early) version of Guile-Emacs, you can get some rather horrific error messages.

It needs work to get a seamless experience, but I'm optimistic. The benefits we will be getting are huge IMO.

> Since Emacs is primarily a text editor, historically it has been forgiving about incorrectly encoded characters, in the interest of letting users get work done—it will happily convert invalid sequences into raw bytes for display purposes, then write them back as-is when saving a file.
> But Guile has other use cases to worry about, such as executing programs which ought to raise an error when an invalid character sequence is encountered.

I think that whole topic was blown out of proportion. What we want is simply that Guile's normal string API works with valid UTF-8 only by default, but there are knobs you can play with --or an extra API-- to allow badly encoded data. Emacs will then use those knobs/API to keep its current behavior. There is no fundamental issue here; Guile will just have to support both use-cases and Emacs will use the right one for its purposes.

> So Guile-Emacs picked one of those as being Elisp's nil, so as long as you stay all within Elisp things work just fine (presumably), but as soon as some Scheme gets into the picture you might get new values which are similar to nil but aren't `eq' to it.

The last part is wrong and I'm partly to blame for spreading that claim. Here's the correction:

According to Templeton, Elisp's `eq' will consider Scheme null, Scheme false, and Elisp nil to all be `eq' to each other. The current Guile-Emacs behavior is just a bug.

So when writing Elisp code, you have *no* issue whatsoever.

The same doesn't go for Scheme though; `eq?', `eqv?', and `equal?' all distinguish between the three objects. So Guile Scheme code, if it interacts with Elisp code, has to be careful. This doesn't affect vanilla Emacs users using Guile-Emacs, and neither does it affect vanilla Guile (Scheme) users; it only affects those who want to go on to adventures and extend or control Emacs via Scheme code.