Are these edge cases correct to the spec, or not?

Yes.

The spec is often such a confused mess that even the people who wrote it are surprised by what it requires. One example was when someone on the PKIX list spent some time explaining to X.509 standards people what it was that their own standard required, which they had been unaware of until then.

Most IT departments educate users about the dangers of macros in MS Office files of suspicious provenance.

The instruction may be in a .txt file, which is usually deemed safe and inert by construction.

> We are taking inquiries and orders for January 2026.

Hence the relevance, maybe.

I wonder what prevents a GH action from connecting to your VPN (Wireguard is fine) and post tons of diagnostics right onto your screen, and then, when something goes badly wrong, or when a certain point is reached, to just keep polling an HTTP endpoint for shell commands to execute.

I mean. I understand, it would time out eventually. But it may be enough time to interactively check a few things right inside the running task's process.

Of course this should only happen if the PR contains a file that says where to connect and when to stop for interactive input. You would only push such a file when an action is misbehaving, and you want to debug it.

I understand that it's a band-aid, but a band-aid is better than the nothing which is available right now.

Obviously, by doing everything inside a container, where you control things. The GH action should only start the container, and pass it some env vars.

I would say that omitting the crucial detail about the unlimited slow speed access is pretty misleading. It's a difference between needing to set up a fallback channel, and not, which halves the complexity.

> 4. No Magic – No hidden allocations, no garbage collector, no virtual machine

I assume also "5. No stdlib"? Will it be even able to print("Hello world") not by doing a direct write() syscall?

Right now there’s intentionally no stdlib, so yes, printing would ultimately boil down to a direct write syscall. The idea is that the core language stays as thin as possible and anything higher level lives on top of that, either as compiler intrinsics or a very small stdlib later. For the MVP I wanted to make the boundary explicit instead of pretending there’s no syscall underneath. So “Hello world” will work, but in a very boring, low level way at first

Indent-based syntax is relatively simple to parse. You basically need two pieces of state: are you in indent-sensitive mode (not inside a literal, not inside a parenthesized expression), and what indentation did the previous line have. Then you can easily issue INDENT and DEDENT tokens, which work exactly like "{" and "}". The actual Python parser does issue these tokens.

Actually Haskell has both indent-based and curlies-based syntax, and curlies freely replace indentation, and vice versa (but only as pairs).

> You basically need two pieces of state

That’s enough for INDENT, but for DEDENT you also need a stack of previous indentation levels. That’s how, when the amount of indentation decreases, you know how many DEDENTs to emit.

The requirement for a stack means that Python’s lexical grammar is not regular.

Maybe you can even forward-bias your panel, and make it generate some heat off the battery power. (It may even glow a tiny bit.)

Basically, if it's in the commit history, it can be checked out and adjusted to the local circumstances. If not, then somebody has to actually write it!