[lolinder]

This is a pretty neat application, but most embedded languages like SQL have a way more complicated grammar that would require a really complicated set of types to parse. This can tank the performance of your type checking step and it also means that the error messages you get out of the parser-in-types are going to be nearly useless.

A more common solution is to parse the string at runtime with a proper parser with decent error handling and then have the parser return a branded type [0] which you can use elsewhere to ensure your strings are well formed.

[0] https://egghead.io/blog/using-branded-types-in-typescript

[taeric]

I'd expect that for most SQL that is being inlined in code, you could get by with only supporting a subset of what is possible. I also have no doubt you could easily sabotage the effort by trying to support every dialect of sql in a smart way. :D

I'm also curious on the idea of having a string parsed at runtime and why that is necessarily better? Sounds like this is essentially dynamic typing? Where they are calling it branded, instead of dynamic? At first, I confess the idea sounded close to a tagged union. You have to have something in the data to indicate the tag; but I guess it is missing the union part? Definitely looks close to the idea of treating "objects" as maps.

Neat idea, thanks for sharing!