Posted by teleforce 1/7/2026
We already have it. It's an obscure little language called C++. Tise interested in those kinds of extensions to a language should look into Herb Sutter's experiments with cppfront: https://hsutter.github.io/cppfront/welcome/overview/
Lisp is what you are after if you want to include some object system as a library, or a new type of switch statement as a library or a new kind of if statement as a library.
C++ can do none of that.
OK, if you squint enough that by "block of code" you mean closure, or function object, then I can write that in C++. I can make the if statement a free-standing function (that is, not a member of a class), and add it to any library I wish.
Now, you can say that it's going to be tedious to use that, because you have to set up three closures every time you want to call this "super if". And you'd be right, but that's a different argument.
But we aren't squinting here; those closures can't perform a return where your `new-if` function is being used, they can't perform a `return` like a proper `if` can, you can't goto, or break or continue.
It's just a function taking functions, with all the restrictions that that entails.
My point was that you can often get the effect you want with no new syntax. (Cue 10,000 replies that state "but you can't get this effect without new syntax!" Perhaps not. Many of those tend to be rather contrived, though. I'm more sympathetic to the argument that new syntax would make something less clumsy. If it's something you need to do a lot, that matters.)
https://learn.microsoft.com/en-us/cpp/mfc/tn038-mfc-ole-iunk...
It is the best way? Probably not, but we seldom get to chose what mainstream languages win out on the field.
But, if you squint, great API design is a bit like embedded domain specific language design as well.
I think there's room for both.
It looks that somebody listened. We now have 3 GTK libraries in a system, a lot of graphics libraries (cairo, etc) 3d libraries (Mesa, vulkan). It is a mess.
Although that in itself might be a hint to change language and write your library there, instead of inventing a new one.
yet at the same time, clojurists love the idea of doing lots of dsl libraries..
the key is that not all worlds enable the same kinds of libraries.
- and runs 50 times faster than c, c++, rust and zig
- comes with a standard library covering 50000 use cases
- has direct integrations with drivers to every major database, crm, analytics provider, key value store, queue systems
https://source.android.com/docs/core/architecture
Also Koltin is meaningless without Java Virtual Machine, which is used to power most of Koltin existence[0], Gradle, Android Studio, thus the Android team keeps updating the Java support so that they don't lose access to the most used versions in Maven Central.
[0] - Kotlin Native and Kotlin Javascript are quite poor in available libraries
> At this point, the right question to ask would be, well can you write a static-typing library for Scheme that then automatically checks your code for type errors? And the current answer, for now and for the foreseeable future, is no. No mainstream language today allows you to write a library to extend its type system.
The author seems to provide a counter example themselves(?):
> Racket and Shen provide mechanisms for extending their type systems...
I wonder if this is as clear-cut as the author is making it out to be. Coalton, which is effectively a library (and language) for Common Lisp, seems like it basically does this. Maybe that's not exactly what the author is referring to, because it is essentially a new language on top of Lisp using its meta-programming facilities, as opposed to merely extending the type system. Still, it can be used as a library right alongside Lisp code, so I think it's in the same spirit of of the first question of writing a "static-typing library that automatically checks your code" in a dynamic language.
Standard scheme may or may not be able to do this, but most Scheme implementations have unhygienic macros like CL's too, so I'd assume something similar would be possible. The fact that that these tend to be extensions from implementation designers might align with the article's point though. Also somewhat to the author's point, Coalton does rely strongly on CL's underlying type system, for which there's no real equivalent in Scheme. It also relies on implementation-specific optimizations alongside that.
For what it's worth you can (and indeed people have) written object systems in Scheme, despite the language not having one, though they tend not to be performant, which is likely another point towards using/writing a different language. CL also tends to allow fairly deep extension of its object system through the Meta-object Protocol.
I guess my point is that in my (probably biased) opinion, Lisps, or other languages with very strong meta-programming facilities, are pretty close to the language longed for in "Perhaps one day we'll have such a language." They aren't a silver bullet, of course. CL has no easy way to write performant coroutines/continuations, for example, even given all its extensibility. Scheme has no real type system, etc. etc.
I don't think any of this invalidates the articles points, I'm just not sure I agree with the absolutes.