As a related work regarding continuations, there was also a thesis by Andrea Bernardini (https://andrebask.github.io/thesis), with similar principal idea

> shows how powerful Racket can be for building programming languages!

Building languages was always one of selling points racket tried to push; the "Language-Oriented Programming Language" slogan and all.

And it's true, and one of the reasons that Racket (and other beefy Schemes) is easily tied for my favorite language.

But I have to use other languages, like Python, JavaScript, and Swift, for employability and (sometimes) ecosystem/integration reasons.

you might be interested in Hy lang

as much praise as some people give to it, I feel deeply uncomfortable with an idea of SaaS-only DB tech that you don't have an option to self host

Agreed. I personally am very uncomfortable with the idea of SaaS-only DB tech. Databases I deal with are very large. And we are a small company. Self-hosted works for us. We cannot afford hosted database solutions as they charge by storage and some also by data transfer. From my point of view, 3rd party hosting of databases solves problems we don't have. Particularly with AI tools managing our services using ansible/terraform, I think we'd be worse off if we switched to a SaaS product.

same, and unlike other repliers, I'll say one doesn't need to reinvent a new tool for this. Just use devcontainers.

Same, I've also been running with `--dangerously-skip-permissions` in devcontainers with docker volumes to keep Claude/Codex auth tokens.

Works really well!

all the things, if macro system is sufficiently sophisticated (ie., hygienic with ability to attach metadata to syntax object). Racket is one of languages with such system, and they implemented static typing using them.

Interestingly, Let Over Lambda eschews hygienic macros because they limit the power (and danger) inherent in macro design.

IIRC, the criticism is of syntax-rules and syntax-case kind of macros in Scheme; I don't recall (happy to be proved wrong) LoL directly mentioning syntax-parse that's specific to Racket. syntax-parse is no less powerful than defmacro; it's just (much) more structured and featureful. It's a difference between hand-rolling a recursive-descent parser and using a (really robust) PEG library.

Racket's define-syntax/syntax-parse has escape hatches into procedural generation (through which you can easily break the hygiene), and the equivalent of CL's &environment contains more information and allows more operations in Racket. Racket also supports reader extensions but often doesn't need them because it has a macro-based API for module definitions (a feature completely absent from, or even alien to, Common Lisp; OTOH, Elixir borrows some of Racket's ideas in this space).

For a practical example, Coalton and Typed Racket implementations show that both systems are capable of large-scale language extensions. I never studied their respective codebases, so I can't say anything about relative ease of introducing those extensions, but they are possible in both cases, at least.

what I meant, the macro system should support hygiene, not necessarily that all macros in it must be hygienic. The syntax bits being manipulated come with an extra scope context, which means you get better preserved information about initial structure of your program; the more information macro has, the more it can achieve. And crucially, in a macro system capable of hygiene, you're not implicitly losing unhygienic capabilities. Implementing unhygienic macros in a hygienic system just means deleting all the scope information. Implementing hygienic macros in unhygienic system is a question mark. As (a somewhat imprecise) analogy, consider dynamic vs lexical scoping. If you have just lexical scoping support, you can mimic dynamic scoping with globals (since global scope is what's left when you delete other scopes). If you have just dynamic scoping support, implementing lexical scope is a question mark.

What Let Over Lambda calls limited power, is probably in reference narrowly to `syntax-rules`. It's not just that it's hygienic, but that it purposefully has no way to opt out of it (unhygienic capabilities in a hygienic system are trivial to provide; but they still need to be provided by language implementation) but what's even more limiting is that it doesn't let you write procedural macros, it's all arcane pattern matching and templates. `syntax-case` (part of r6rs) doesn't have these issues.

I used opportunity to learn about devcontainers. I've only recently started using llms and it's possible I'll change my mind later; but so far I quite like the approach in part because it 2-for-1 also gives benefit of easy to setup coding env for people who don't care about ai.

it's a very old idea. I first saw this on https://www.squidi.net/three/entry.php?id=56

one of the players he persistently harassed, Daniel Naroditsky, ended up dying, which surely gave an extra push

It took 6 turns for opus 4.8 to attempt to make an illegal move in chess against me.

Yes you can setup guardrails and validations and other things, but as long its primary brain is demonstrably full of holes, I feel obligation to at very least be always be capable to take over the code. To me this means it should stay human-maintainable, and that's for humans to decide what is and isn't, one review at a time.