hayley-patton

I think module-null-sink and module-loopback could be used to create a virtual source which combines multiple sources, though the source/sink thing makes my head spin. Or, more simply, I suppose using the loopback of whatever audio output device does the combination (and the same mixing) for you, if you play all audio through one output device (which is most likely)?

I got lazy, to be fair:

MORE book burning -X-> multi location backups -> book burning -> passing down fables -> the ever-finite span of life -> convection and time -> volcano induced winter -> lots of lava -> lots of water -> base -> acid -> angle grinder -> hammer -> rock

Does it give real citations? I've heard it gives bogus citations, though can't remember how well it went last time.

Narrator: "The code did not, in fact, auto-vectorise."

(There's only addsd/movsd instructions, which are add/move scalar-double; we want addpd/movpd which are add/move packed-double in vectorised code.)

Dang, it's the shadow stack paper, not the BDW one! Sorry, my comment doesn't apply to shadow stacks and thus doesn't apply to the article.

We're going to put just a type ID in the word - you could probably get away with much smaller than a 64-bit ID, but padding will round it up to 64 bits in any case. The heap has exactly one tracing function and size function for all objects, and the functions check the type ID to determine what type they're looking at.

Where do you get 24 bytes of overhead from? A mark-sweep collector only needs a bitmap of 1 bit per alignment granule.

edit: oh, that's what the article uses - the tracing function and size function can be per-heap and the forwarding pointers can overwrite the start of objects, to just have enough header to support tracing and sizing, which could be one word.

> In a custom language, this can be implemented very easily following the approach outlined in this paper: Accurate garbage collection in an uncooperative environment.

Cheney's algorithm and conservative roots don't mix too easily, as you cannot move conservative roots: an integer which looks like a pointer shouldn't be changed by moving. https://dl.acm.org/doi/10.1145/2660193.2660198 has an overview of algorithms which don't move conservative roots (including never moving, as in Boehm-Demers-Weiser).

Omega combinators would have made for better growth hacking.

> but the fact that it then supports Scheme macros

Good for them.

> possibly share code between developing for the PreScheme compiler target and non-PreScheme targets

"possibly" is a strong word, seeing that Pre-Scheme is a statically typed, explicitly memory managed subset and all. There's a very large and coarse-grained semantic leap.

Then you can read the rest of <https://www.steveblackburn.org/pubs/papers/vmmagic-vee-2009....>, for a bonus.

"Unhappy the land that has no heroes!" "No. Unhappy the land that needs heroes."

The hell of the systems language is the systems, not that it has infix syntax.

This one? https://gist.github.com/no-defun-allowed/4f0a06e17b3ce74c6ae...

It also responds to a few parents up "almost all of the innovations in lisp [...] have been absorbed into more popular languages" - pervasive interactivity hasn't even been taken up by some "Lisps", let alone has it been absorbed outside Lisp.

It has data races. Why would SBCL have a borrow checker?

> The first observation is that you can't do it at compile time. I've seen at least one blog entry that used a bytecode hack to replace a CALL opcode immediately before a RETURN opcode with a jump to the top of the function body. This may be a nice demo, but unfortunately Python's compiler cannot reliably determine whether any particular call is actually reference the current function, even if it appears to have the same name.

Tail call elimination should handle mutual recursion too, so this is completely unnecessary to check, and any CALL in tail position should become a tail call. Ironically I found this post from https://news.ycombinator.com/item?id=40504141 which is all about using mutual recursion to encode automata.

I also suspect the author meant "humongous" in:

> Shenandoah is location-based, so there are regions, and region sizes, and therefore _homologous_ allocation is a special case to be handled.

It's especially hard when you don't have semantics for your language outside of what your interpreter does. Then the semantics of the language in the book are plain bad: there is only dynamic scoping (oh, and the book often has plain misinformation - the provided definition of "lexical scoping" is wrong), and setting a local variable only affects the innermost LET if you nest environments, since the interpreter deep-copies environments (as it does with everything, to cope with lack of GC).

The book also uses something more like fexprs than macros, which I don't have an opinion _outside of this book_ on with regards to language UX, but fexprs are generally harder to compile. That is in part because they control if/when their arguments are evaluated, but the fexpr-alike things here do not (instead "Q-expressions" delay evaluation like QUOTE). You still would want to do something about calls to EVAL though. The fexpr system _in this book_ also does have bad UX: it only incidentally works with dynamic binding (Shutt's lexically scoped fexprs explicitly pass the environment around) and it also leaks every variable binding from the fexpr function into what it evaluates.

The book also just doesn't cover compilers, so you're doing that slog on your own.

It is a very bad start and teaches writing an interpreter and not a compiler. https://gist.github.com/no-defun-allowed/7e3e238c959e27d4919...

I can no longer google "ML Kit" and find the ML compiler, instead I find Google's ML library. You win some, you lose some.

There's a lot of language semantics which make the REPL convenient to write interesting amounts of code in, Gilad Bracha details some in <https://blog.bracha.org/primordialsoup.html?snapshot=Amplefo...> (with the message reflected in the medium, embedding the Newspeak IDE in the document for examples). It's unrelated to compiling or interpreting; many Common Lisp implementations will compile code from the REPL too.

Implementations interpret, languages don't; PyPy compiles and is about half the speed of V8. But one should put micro trust in a micro benchmark in general.

Compile SBCL with the command ./make.sh --with-mark-region-gc and the resulting build will use the mark-region GC. (Picking the GC at start-time instead of build-time would be very nice, but technically hard to pull off unfortunately.)

I can view it just fine in Australia. Now I'm going to download a car too before I get caught.

SBCL cheats and copies starting from the first cons cell that is referenced from outside the list; this tends to be the start of the list, and so traversing just works. The contiguous copying also ends when a cons cell which was already copied is found, so there can't be more discontinuities than there are cons cells referenced from outside the list, regardless of which order we discover the references.

SBCL tries its hardest to allocate sequentially, then moves lists to be sequential in GC.

The Smalltalk special of Byte Magazine infamously has a hot air balloon floating away from an island with ivory towers on it. Flying things measure their altitude in feet, but the low level is low. Furthermore, according to Tubeway Army, bombers fly at zero feet <https://www.youtube.com/watch?v=GAj89NEqX-M>.

This isn't about Lisp in the browser though, it's about high-level low-level programming (to borrow the name from Daniel Frampton <https://www.steveblackburn.org/pubs/theses/frampton-2010.pdf>).

What was Brendan Eich doing that is covered in this article?

It's not always faster, so making it the default could cause regressions; it seems pretty stable now but the default (gencgc) had a head-start of a few decades for bug finding (and making).

But Multics was written in PL/I (and the Burroughs B5000 system in Algol before) so Unix doesn't have an advantage there.