Finding out about how, in a programming language with dependent types, types can be returned from functions like values, feels about the same way as when I learned functions can be returned as first-class values in functional programming. It went from "wait, what?" to "of course, why wouldn't you be allowed to do that?" From seeming confusing to seeming perfectly natural, leaving you more confused of its abscence than its presence. Though admittedly, I don't have much experience with using dependent types seriously.<p>This property of dependent types:<p>> In fact, if you don't mind writing a proof or two, our sprintf function can be called on format strings that aren't fully known at compile-time! You only need to be able to prove that the string will have certain format specifiers, and then calling sprintf can typecheck.<p>It's not new to me, but I also find it pretty cool. Proving things at compile-time that certain runtime conditions will hold using a programming language is so much cooler than just proving it to yourself in your head or on paper, and then doing a runtime assertion in the actual code. Or, not doing a check at all, and just having crashes or security vulnerabilities if you're mistaken.
Sometimes I dream about a Rust-like programming language with optional garbage collection similar to Swift that runs in three stages: The first one is an idempotent interpreter so heavily sandboxed that it can only read the source code and output only diagnostics and the second stage: a more static programming language. Meta-programming!<p>This would allow simplifying the second stage massively because it is generated code and won't need ergonomy. This programming language would parse the sprintf format string exactly as if the compiled program would do it at runtime. When I read the article I thought to myself, aha, dependent types, could it be that it is similar to a user-provided program that computes the types?<p>I have to disclaim that designing programming languages is not my expertise. I am only an amateur.<p>These two stages avoid the complexity of Rust compile-time handling. Instead of hard coding things like lifetimes, generics, const generics, return position impl trait in trait (RPITIT), async fn in trait (AFIT), and so on, have a first stage standard library handling all these things.<p>And the third stage? A sandboxed interpreter with the same or similar syntax as the rest of the thing. I think this would be useful as glue code or just for tiny throw-away scripts. All these three stages would profit from a common base, so they should be provided together.<p>Makes sense?
I am at a loss to understand this. I learned C in 1989 and sprintf takes a minimum of two arguments, but typically takes three or more, the first one being the string for the output to be written to. Perhaps the author was writing about printf, which takes a minimum of one argument, but typically takes two or more?
Nice writeup! It would be helpful to seen an actual invocation of the new sprintf function<p>I know it's supposed to be pseudo code and most likely it's something like sprintf "% world %d" "hello" 42 but I got a little confused by the type list being backwards from what I expected