thechao

I've been having thoughts along these lines. Earley parsers match recursive descent really nicely. In my head there'd by an Earley parser "oracle": you'd tell the oracle about the operations you've performed (in terms of terminal consumption); and, then, you can ask the oracle which recursive descent subfunctions are safe to call (based on the prediction phase).

The naturally clamp tightly to the spirits of the dead. Don't wanna be dragging your dead great aunt's ghost the night club.

Dear map makers who show us by-state break-downs: normalize by the population. The first map tells me this: New York, Florida, and Texas have large populations.

If I'm interested in performance I'll build my data out of offset handles and lay everything down into a block and mmap() it around. That's parsing free, up to an htons() — but that's only a worst case scenario. Everything else is about not inventing something custom & being able to use easily vendored high-trust 3rd party tools. (In this case: a JSON library, LZ4, and/or SQLite.)

I do a lot of very low level programming with awful performance-maintenance trade-offs. Here's a great trick for a "binary" JSON: remove all of the extra whitespace, normalize your numbers, and the LZ4 the resulting string.

UTF-8 is already a great wire format.

I've never found a "binary JSON" that's significantly better than this; I mean you can beat it, but you need awkward encodings (prefix indices & other weird shit). You end up burning nearly-byte for any particularly clever integer encoding.

Most data structures are just nested arrays of integers. If you need an integer keyed OBJECT you're SOL, but I just play fiddly games with astral plane UTF-8 characters. (Yeah yeah yeah ad hoc encodings are nasty news.)

If you've got a BUTT LOAD of data just fire up a compressing SQLite DB like a normal human.

My wife really wants to build a house; we've started by doing some light remodeling using GC's who also build houses to a "get a feel for it". There's a strong incentive for a good GC to truly believe the estimate he gives you. (They're all dudes, around here.) However, that estimate is rarely close — usually the budget goes over 50–100%. Here's the thing: the GC gets paid off the total cost, not the original contact, and he gets a cut of the cost. So, really, there's no incentive at all for him to control costs.

A buddy of mine works for a large grocer down here (HEB). The way HEB builds is that they get a build contract and a bunch of lawyers, and the GC has to demonstrate that they have enough assets that HEB can go after to make them (HEB) whole. If the GC goes over estimate, then that's on the GC, not on HEB. HEB gets a building or they take the money back.

As an individual, you can "act like HEB" by going with a major builder. Down here that'd be Pulte or someone like that; alternately, there's a lot of high quality factory-built custom homes. I'm trying to convince my wife that we should build a metal building on post-and-beam with a crawl space. We can build a minimum viable house for 25¢/$ compared to a custom, and the quality is straight-up an order-of-magnitude better. The rest of the house can be finished out using off-the-shelf components.

That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.

This is effective feature size and has little to do with actual geometry. Transistor size has barely budged in the last 10–15 years. The limitation is electrical, and it's not clear where that limit is. The smallest gate was built with an AFM out ~7 atoms; that's about 8 orders of magnitude smaller than a transistor, rn, and upwards of 9 than a stdcell. There's a LOT of room; we just don't know a good path to get to there.

I wonder if it's possible to not lock themselves into an ABI with a built in vtable implementation? I kinda get where they're coming from: let vtables be a user problem; but, yeah, modern compilers can do magic when they "know" the rules for built in vtables. It kinda feels like they're leaving a real performance opportunity on the ground?

Right. Because your average citizen has a few hundred thousand dollars for their rare congenital disease. My bet — just wild eyed speculation — is that most of this stuff is paid for by the govt through sone sort of insurance-like subsidy. That means the risk is really borne by the tax payer.

Let's just cut out the middle man.

TSMC has 83000 employees. If Intel does everything TSMC & NV do, then they should have something like 83000+36000~120000 employees?

All the stars in the universe, burning as brightly as they are, are the tiniest fraction of additional energy compared to the 2.73°K background temperature of space. The Big Bang was very warm.

I agree. But, I also like the discipline of lexing from `FILE*`. I've ended up with cleaner separation of concerns throughout the front-end stack, because I can't dip back into the well, unless I'm thinking very clearly about that operation. For instance, I keep around coordinates of things, rather than pointers, etc.

At the parser-level, though; not down in the lexer. I intern unique user-defined strings (just with a hashcons or whatever the cool kids call it, these days). That defers the determination of correctness of UTF-kness to "someone else".

I like to have my lexers operate on `FILE*`, rather than string-views. This has some real-world performance implications (not good ones); but, it does mean I can operate on streams. If the user has a c-string, the string can be easily wrapped by `funopen()` or `fopencookie()` to provide a `FILE*` adapter layer. (Most of my lexers include one of these, out-of-the-box.)

Everything else, I stole from Bob Nystrom: I keep a local copy of the token's string in the token, aka, `char word[64]`. I try to minimize "decision making" during lexing. Really, at the consumption point we're only interested in an extremely small number of things: (1) does the lexeme start with a letter or a number?; (2) is it whitespace, and is that whitespace a new line?; or, (3) does it look like an operator?

The only place where I've ever considered goto-threading was in keyword identification. However, if your language keeps keywords to ≤ 8 bytes, you can just bake the keywords into `uint64_t`'s and compare against those values. You can do a crapload of 64b compares/ns.

The next level up (parsing) is slow enough to eat & memoize the decision making of the lexer; and, materially, it doesn't complicate the parser. (In fact: there's a lot of decision making that happens in the parser that'd have to be replicated in the lexer, otherwise.)

The result, overall, is you can have a pretty general-purpose lexer that you can reuse for a any old C-ish language, and tune to your heart's content, without needing a custom rewrite, each time.

Which language is phonetic? I think you're beating around the bush here; you claim English isn't phonetic, but which language is?

I think you're trying to to argue something like: "the set of dialects that make up English have a large(r?) set of allowable IPA orthographic representations than the accepted set of English orthographies" or something to that effect? And, that, perhaps, Spanish (French? Ukrainian?) have a much smaller set of alternate IPA orthographies for a given acceptable orthography?

I guess I'm really confused. It's not like English is some Arabic language where the orthography is in a second nearly unintelligible languages? Or, Chinese or Egyptian hieroglyphs... ?

I'm tired of bailing Floridian and coastal Texans out after hurricanes. I'm in Austin (Texas) and our insurance bills are outrageous because of coastal cities (indirect, if nontrivial). If they want to live down there, fine, but I don't want to bail them out. Houston & Corpus are the worst offenders: they produce huge amounts of CO2 per capita, and then demand bailouts when climate change fucks them over.

We need to distinguish between a computer that's equivalent to BB(n), and a computer big enough to compute the value of the number that is BB(n). By (terrible) analogy: a 4004 can be made to write a finite loop that describes how many FLOPs the number 1 supercomputer can compute without, itself, being able to usefully perform the computations of that supercomputer. (The 4004 will run out of memory/addressable disk space.) Similarly, we can no longer build decidable programs in ZFC that can compute the number BB(748). Scott is saying that they now think this "disassociation" might occur at BB(7)!

I've found it easier to write my own PRNG than to use the std. Using the std PRNG is about as buggy as my implementation, so the trade-off is reasonable. I usually need non-cryptographically strong PRNGs, so xorshift128+ is sufficient.

Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well!

Also, I want a cookie & a pony.

Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.

Even at .0006c (our current tech), the galaxy would be filled with (weakly self propagating) robotic probes after just 750 million years. Unless extremely long lived self-propagating probes just ... die out ... that implies no aliens older than 750 million years from our galaxy. It implies no aliens from the nearby galactic neighborhood within 3 billion years. That kind of implies we're all alone.

I have three wild-eyed theories: (1) eukaryotism is an unbelievably exotic step; (2) and/or the moon is required and ultrarare; or, (3) advanced civilizations eschew yellow stars for being inconveniently short-lived: maybe they prefer brown dwarfs, white dwarfs, or black holes for their energy gradient.

Most people tend to punch with a loose hand to the top of the head: this simultaneously increases the chance of breaking their hand; reduces the impact force; and, strikes one of the most insensitive & hardest parts of the body (the skull). Trained fighters are targeting an untucked chin with a short high acceleration punch (jab, uppercut), with a tight fist. It is technically very challenging to do this, even for professionals.

In general: use your sneakers; if necessary, push opponents away with with your palms and tightly held fingers.

House size, build "quality" (the details in the house), resource scarcity, and zoning policy are the drivers of cost. Cheap credit and lifetime loans allow the system to continue.

I remember an Analog "speculative engineering" article from a few decades that pointed out that plain old structural steel, at the appropriate height of the surface of Jupiter would create a surface with "natural" 1g of gravity. For structural reasons, the ring would have to be spun; but, really, it's just a Niven ring but Jovian-scale. (Lest this be too confusing: the direction of "down" in a Niven ring points antisunward; a Jovian ring points down to Jupiter.)

Modulo the launching of material, scientific needs, etc., there no reason it couldn't've been built by Brunel in Victorian times. Well... scale, as well, I suppose.

"Staple" as in "potato"; not "paper". Although, I'm fond of both metaphors — the initial mixed one was very delightful!

Hold my beer; I'm gonna middlebrow this! My best guess (dimly remembered from drawing blood for testing in my lab) is that these "groups" (systems?) all live at the same place on the chromosomes that do/n't express them — they're alleles.

Dijkstra!

Sigh: https://arxiv.org/abs/2505.23877