rainbow-delimiters VS sixten

I'm a big fan of rainbow-delimiters, available on Melpa.

rainbow-delimiters ( https://github.com/Fanael/rainbow-delimiters/ ) does this for parenthesis/braces etc but is somewhat bound to the syntax tree of whatever major mode is currently in use, it also scans on a per-character basis, where I'd need to scan for regex.

> Lighting up the active scopes

As you had guessed a little later, there are a few different emacs packages that do this. One of them is "rainbow parentheses" that gives every bracket a different colour (remember that emacs supports lisp, so differentiating between lots of different parentheses is arguably more useful in emacs than any other editor). [0].

Another one is highlight parentheses [1] which highlights all parens that enclose the cursor position, and gives a darker colour to those "further away" from the cursor.

[0] https://github.com/Fanael/rainbow-delimiters

[1] https://sr.ht/~tsdh/highlight-parentheses.el/

This article is especially interesting to me, as it shows how VS Code still doesn't have the "Emacs nature". Even though I'm a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it's so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn't — extensions are limited to using an extension API, rather than having full access to the application's internals. Maybe a good thing, if you're a mass-market product worried about malicious extensions. But I'll note that [rainbow-delimiters-mode](https://github.com/Fanael/rainbow-delimiters/) dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.

Using highlight-parentheses-mode, which is an additional package, helps. There are also show-paren-mode (build in) and rainbow-delimiters (additional package), whose could help there.

Immutable data structures don't necessarily require more memory: they can avoid deep copies. They are also automatically thread safe without expensive (slow) locking mechanisms. They also don't necessarily reduce cache locality. The reduced cache locality in the case of Haskell (I think) mainly comes from the representation of objects in its implementation (improved STG) which uses extensive boxing and jumps that hinder both spatial and temporal locality (require review/comment from GHC/Computer Architecture experts, take it with a grain of salt). Objects can be much more efficiently represented if not for the need to implement lazy (call-by-need) semantics. See sixten and futhark for examples.

[Sixten](https://github.com/ollef/sixten): functional programming with unboxed data by default.

I can't answer this well and don't know of any resources, but I have seen it before in the parser for sixten:

    https://github.com/ollef/sixten/blob/60d46eee20abd62599badea85774a9365c81af45/src/Frontend/Parse.hs#L458

Sixten is a language that allows precise control over memory layout of algebraic data types.

For something more peripherally related, check out Sixten. Its focus is on using unboxed value representations, which is in spirit close to what you are proposing, and some of its ideas might be good inspiration.