Plurrrr

A common trope is how, if one wants to build a game, one should build a game, rather than a game engine, because it is all too easy to fall into a trap of building a generic solution, without getting to the game proper. It seems to me that the situation with code editors is the opposite — many people build editors, but few are building “editor engines”. What’s an “editor engine”? A made up term I use to denote a THIN WAIST the editor is build upon, the set of core concepts, entities and APIs which power the variety of editor’s components. In this post, I will highlight Emacs’ thin waist, which I think is worthy of imitation!

Comprehensions are currently compiled as nested functions, which provides isolation of the comprehension’s iteration variable, but is inefficient at runtime. This PEP proposes to inline list, dictionary, and set comprehensions into the code where they are defined, and provide the expected isolation by pushing/popping clashing locals on the stack. This change makes comprehensions much faster: up to 2x faster for a microbenchmark of a comprehension alone, translating to an 11% speedup for one sample benchmark derived from real-world code that makes heavy use of comprehensions in the context of doing actual work.

The GHC team is very pleased to announce the availability of the first (and likely final) release candidate of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series:

• Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview
• Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell
• GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

• Significant latency improvements in the non-moving garbage collector
• Efficient runtime support for delimited continuations
• Improvements in compiler error messages
• Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this release.