Guile's reader, in guile › 历史的弧线 the arc of history [#259]

就像在你打开收音机并期望听到 威豹乐队 ( Def Leppard ) 时开始出现的许多语言实现一样，Guile 也有下半部分和上半部分。下半部分是用 C 编写的，暴露了一个共享库和一个可执行文件，而上半部分是用语言本身（在 Guile 的情况下是“Scheme”）编写的，并在语言实现开始时由 C 代码以某种方式加载。 
Like many language implementations that started life when you could turn on the radio and expect to hear Def Leppard, Guile has a bottom half and a top half. The bottom half is written in C and exposes a shared library and an executable, and the top half is written in the language itself (Scheme, in the case of Guile) and somehow loaded by the C code when the language implementation starts.

自2010年左右以来，我们一直在努力将用C语言编写的部分改用 Scheme 编写。上周的信件讨论了动态链接的实现的替换，从使用libltdl库替换为在低级dlopen包装器之上的 Scheme 实现。我以前写过关于在 Scheme 中重写 eval 的内容，更近期则谈到在 Scheme 中实现与 C 语言实现相同性能的道路有时是漫长的。 
Since 2010 or so we have been working at replacing bits written in C with bits written in Scheme. Last week's missive was about replacing the implementation of dynamic-link from using the libltdl library to using Scheme on top of a low-level dlopen wrapper. I've written about rewriting eval in Scheme, and more recently about how the road to getting the performance of C implementations in Scheme has been sometimes long.

这些重写有 堂吉诃德式 ( quixotic ) 的一面。我内心深处有一些关于正确与错误的感觉，并且我从根本上知道从 C 转向 Scheme 是正确的事情。很多时候这种感觉都是完全不理性的，在许多情况下也显得不合时宜⸺比如，如果你有一项需要为客户完成的任务，你需要坐下来思考从这里到目标的最小步骤，而直觉对于你如何到达那里并没有多大作用。但有一个项目可以让你按照自己喜欢的方式做某件事是美好的，即使这需要 10 年，那也没关系。 
These rewrites have a quixotic aspect to them. I feel something in my gut about rightness and wrongness and I know at a base level that moving from C to Scheme is the right thing. Much of it is completely irrational and can be out of place in a lot of contexts -- like if you have a task to get done for a customer, you need to sit and think about minimal steps from here to the goal and the gut doesn't have much of a role to play in how you get there. But it's nice to have a project where you can do a thing in the way you'd like, and if it takes 10 years, that's fine.

不过除了难以言表的动机之外，用 Scheme 重写一些东西还是有具体的好处的。我发现 Scheme 代码更容易维护，嗯，而且相比 C 的常见 陷阱 ( pitfall ) ，Scheme 显然更安全。如果有一天我重写 Guile 的垃圾收集器，这会减少我的工作量。而且，Scheme 代码还具有 C 语言所没有的功能： 尾部调用 ( tail call ) 、 可恢复的分隔延续 ( resumable continuations ) 、 运行时检测 ( run-time instrumentation ) 等等。 
But besides the ineffable motivations, there are concrete advantages to rewriting something in Scheme. I find Scheme code to be more maintainable, yes, and more secure relative to the common pitfalls of C, obviously. It decreases the amount of work I will have when one day I rewrite Guile's garbage collector. But also, Scheme code gets things that C can't have: tail calls, resumable delimited continuations, run-time instrumentation, and so on.

以 定界延续 ( delimited continuations ) 为例，大约五年前，我为 Guile 编写了一个以并行并发 ML 为模型的轻量级并发设施。它允许数百万条 fibers 存在于系统上。当一个 fiber 需要阻塞 I/O 操作（读或写）时，它会暂停其延续，并在操作变得可能时安排重启它。 
Taking delimited continuations as an example, five years ago or so I wrote a lightweight concurrency facility for Guile, modelled on Parallel Concurrent ML. It lets millions of fibers to exist on a system. When a fiber would need to block on an I/O operation (read or write), instead it suspends its continuation, and arranges to restart it when the operation becomes possible.

为了让这一切成真，Guile 必须做出很多改变。首先是定界延续本身。后来是 Scheme 中 ports 设施上半部分的完全重写，以允许 port 操作挂起和恢复。可恢复 fibers 的许多障碍已被消除，但 Fibers 手册仍然列出了相当多的障碍。 
A lot had to change in Guile for this to become a reality. Firstly, delimited continuations themselves. Later, a complete rewrite of the top half of the ports facility in Scheme, to allow port operations to suspend and resume. Many of the barriers to resumable fibers were removed, but the Fibers manual still names quite a few.