GHC 8.2 Released
ghc.haskell.org> Compact regions, allowing better control over garbage collection in the presence of large heaps containing many long-lived objects.
Can someone explain how this feature works and/or how much impact it has on Haskell's feasibility as a performant, i.e., game engine or real-time application language?
In a nutshell, you can create a region and add data to this region and the GC will never look inside it. That is, as long as there is one external reference to any object in this region, the whole region will be kept alive. This is most useful when you know beforehand that you will never deallocate this region of data anyway: it reduces GC latency. Another benefit is that this region can then be serialized to disk efficiently. Deserialization is pretty efficient as it involves as loading the whole thing into memory and fixing up pointers. Reminds me of the Emacs dump[1] though.
On Ed Yang's repo <https://github.com/ezyang/compact>, which I believe features a version of the Data.Compact module that got merged into base, he gives the example of a spellchecker whose max pauses went from (0.0023,0.0582) to (0.0017,0.0462). In the example the faster version stores the set of dictionary words result you also get disk (de-)serialization, which allows you to amortize the initial cost string parsing.
Unfortunately, I doubt that nondeterministic garbage collection will ever mesh well with high-performance gaming and especially ever with real-time problems. For ordinary systems programming, however, I think it's frequently possible for high-resident-memory applications to build a walled garden for their e.g. in-memory caches or large binary assets.
> A new, more type-safe type reflection mechanism
Does this mean GHC does not erase types at runtime? Or perhaps what do they mean by "reflection" here; I only know it in the context of Java, where it more or less felt like an anti-pattern.
If I understand the paper correctly, reflection in 8.2 involves some crafty use of GADTs and compiler primitives to create a type descriptor of sorts that allows you to decompose values at runtime in a typesafe manner, while still allowing for erasure.
Paper: https://www.microsoft.com/en-us/research/wp-content/uploads/...
Package: https://downloads.haskell.org/~ghc/latest/docs/html/librarie...
Oh wow this is going to be a joy to read, thanks! Only a couple pages in and it already looks well-written and thorough.
Also there's this: "This paper is literate Haskell and our examples compile under GHC 8.0." A 26 page, typeset paper is certainly the longest example of a literate Haskell program I've come across! Wow.
In general, type reflection does mean making type information available at runtime. However, GHC does erase types at compile time.
The resolution of this apparently contradiction is in the type class mechanism. Type classes ("classes" for short) can be seen as functions from type to value that are automatically resolved by the compiler as much as possible. (There are many other semantically-valid interpretations, like predicates on types, proof obligations, etc.)
Most classes are library-level constructs, defined and implemented entirely with libraries, but there are a few special ones that are completely managed by the compiler. One of the few compiler-managed classes is named Typeable, which allows you to request a runtime representation of the type of an expression. It then provides tools for testing if the runtime representations correspond to the same type, and proving two types are the same at runtime. This is useful in the case where you can prove something is type safe, but the type system doesn't provide you with the tools to express it.
Common cases where you end up doing this in Haskell are creating heterogeneous stores with type-safe keys, or mechanisms like GHC's exception system.
Anyway, the new part here is the addition of a variant of Typeable. It gives more information at compile time so that it can enable a few more tricks within the type system and the implementation doesn't depend on as many unsafe internal primitives.
Cue a full month of regular busloads of archlinux package updates...
This is an impressive list of new features! Well done to all involved!
Where can one find more information on the module system? The release notes don't seem to mention it.
Here is the proposal that landed in the ghc-proposals GitHub repo, written and hand-illustrated by Ed Yang. https://github.com/ezyang/ghc-proposals/blob/backpack/propos...
A/V fans will enjoy this talk by Ed, whose energy and enthusiasm for the extremely dry world of language module design knows no bounds. Also hand-illustrated! https://www.youtube.com/watch?v=Rda6SNhznRs
Guess soon we'll have a new release of the Haskell Platform...
haskell's pretty cool, i guess. sometimes looks like an inscrutable APL descendant with all those wacky operators.