Then if the language allows mutation of objects, special consideration has to be given to old objects that were mutated to point to new ones. You can treat those as additional roots; the graph of young objects reachable from a mutated old object is reachable. (Considered so on the assumption of the old object being reachable, which we can only disprove by doing a full scan.)

I wrote one for TXR Lisp which there are no generation heaps; but objects have a generation. In the same heap, you can have adjacent (unrelated) objects that are in different generations. Objects never move from their heap; they keep their position in the same heap over their lifetime.

The allocator therefore records the new generations in a fresh log, which serves as the nursery. When that log gets full, a pass is triggered.

Implementations with separate heaps (typically copying collectors) allocate in a nursery heap and promote objects from there, but it is conceptually similar.

In the marking phase, we do not process this nursery. We start at the usual root pointers: stack, globals and proceed with normal marking, like in a pure mark-sweep collector (or a full pass), with a small modification: whenever we hit an old gen object, we skip it. We assume that the old gen object is reachable, and every object reachable through it is similarly an old-gen object. This is where the generational algorithm wins, chopping down the graph of objects to be marked, possibly drastically so.

Where the nursery/fresh log comes in is the sweep phase. Because we know that we did not traverse any old generation objects, it would be wasteful to do a full sweep. In the case of the fresh log, we sweep just through the fresh log. Anything in the fresh log that is reachable is promoted to the old generation. Anything not reachable is reclaimed: either immediately or through the finalization treadmill, if applicable. The fresh log is then reset to empty. In the case of a nursery, we similarly just sweep through the nursery heap and promote (by copying) reachable objects to the old generation, reclaiming the rest. The nursery is empty.

There may be additional structures. Note that we have the assumption that old objects only point to old. But what if (it is allowed that) the program mutates an old object to point to a newly allocated new one? That would break the assumption. We can make the program (code generated by compiler or whatever) report whenever that happens.

In the TXR Lisp implementation of generational GC, mutation of old objects is handled via two strategies. A single value assignment of a young object to a field in an old one will cause the young object to be appended to a "check" log. In some cases, this is not practical for various reasons. For instance, an operation mutates a large number of fields of the same object (e.g. array). In such cases we add the old objects to a "mutated" log. The objects added to both arrays have their generation field reset to -1: neither young (0) nor old (1).

Both the check log and mutated log are marked during marking. The check log contains only young objects and so sweeping those is already taken care of by the freshlog, it needs not be visited during the sweep phase.

The mutated log is processed during sweep in order to reset the generations from -1 back to 1.

When the check and mutated logs fill up, GC is not triggered immediately then, but the flag is set for the next GC to be a full one. What that does is turn off the mechanism: since we know a full GC is coming, we don't have to record mutations of old objects pointing to new.

  void foo::method(const &smart_ptr x) { ... }

That's a strange thing to assert, having acknowledged the existence of generational GC.

Small children should learn some kind of Lisp, and easily can.

Richard Stallman famously shared an anecdote in the article "My Lisp Experiences and the Development of GNU Emacs" (https://www.gnu.org/gnu/rms-lisp.en.html) about the secretaries:

> The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

People, whether inside or outside of Lisp, who spread myths that that it is some scary, esoteric elite family of languages, have been pretty harmful.

Or was hard to write selectors against before, you know, AI.

It seems ironic to give up now. You can probably rig up an agent to automatically look for new div labyrinths and write selectors for them.

You can bet Facebook are using AI to generate these labyrinths!!!

I got hurt there two weeks ago. I swerved right around the pole. Unfortunately, just after the pole there is bad drainage, with inches of accumulated dirt. Though it was a sunny August day, there was a thick mud puddle due to it having rained the previous day. I had not seen any patch of wetness anywhere all day; it all concentrated there. That in itself wouldn't have been a problem, had I gone straight through the mud. Unfortunately, maybe two meters after that point, some scavenging person left several garbage bags of junk (such as wire to be recycled). After swerving right around the pole, my attention was on the bags which I planned to avoid by swerving left again. My back tire skidded on the strip of mud and I fell over.

Though I had no scratches or bruises anywhere, something happened to my left knee. I don't remember having landed in any funny position, and there was none of the typical pain from after an impact. But I noticed a sharp pain in the knee after standing up and trying to get back on the bike. It became very painful and swollen the next day. I was not able to straighten the leg or completely fold the knee. It became impossible to crouch down. Putting a sock or shoe on the left foot became a challenge. Multiple places are sprained in that joint, it seems. I've had hip pain as well, as if shooting up the hamstring or IT band from that knee to the hip.

Two-and-a-half weeks later, it's showing only small signs of recovery and slightly improved mobility. I can fully straighten the leg and I've been able to bend the knee all thee way with my hand (no weight on it: that hurts like hell). Had an X-ray last week. I don't know the result; nothing might show. Dr's office called today for a follow-up appointment in two days.

The ironic thing is that I had crossed the entire bridge deck in a vehicle traffic lane, not on the bike/pedestrian walkway! I decided to get off the road and enter this last stage of the walkway, just before that pole, to avoid the traffic pile up on the off-ramp due to big trucks taking up most of the shoulder and whatnot.

Someone writes you a check. Can you easily cash that with your bank in another country? Best scenario: they have a check cashing app for your phone, so you don't have to mail anything off or present in person; but will that take an American check?

A compression program can compress a book written in a language that the author of the program doesn't understand, on a topic he knows little about.

When you shorten a description in a lossy way, you are deciding a priori that some differences in the object don't matter, and it's not because you understand the object, but because it serves your goal of shortening the description.

Because most of the training data has good grammar, the LLM is strongly trained on grammar; it will rarely predict ungrammatical gibberish. Even if there are grammar mistakes in the data, they are not systematic and so don't reinforce each other.

You want the typist to memorize some test sentences so that they are fast enough to demo what the machine can handle.

However, if the phrase was contrived to be sympathetic to the workings of the machine, that would have been a misleading demo.