[ashton314]

We are absolutely swimming in little languages. Consider these languages:

- The language of regular expressions

- SQL queries

- In web frameworks, the language of routes

- etc.

Unfortunately we embed a lot of these languages as strings. This is problematic because the language usually sees just opaque strings—we can't apply any of our lovely static analysis tools to these little embedded languages.

I'm doing some research in this area. We just got a paper published at ECOOP. The big idea is that, with a little bit of clever metaprogramming, we can help the type checker understand these little languages better and give us more helpful hints or execute more efficiently. This isn't a new idea, but no one has given it a name before. Here's the blog post version: https://lambdaland.org/posts/2024-07-15_type_tailoring/

(HN discussion): https://news.ycombinator.com/item?id=40990232

[williamcotton]

I've been playing around recently with a project I'm calling guish.

https://github.com/williamcotton/guish

It is an experiment in using *nix pipelines to put languages on an even footing and not just treat them as strings embedded in strings.

I guess take a look at the screenshot and animated GIF for a better idea of what it does!

[shawn_w]

Racket calls it language oriented programming.

[ashton314]

What, type tailoring? Language-oriented programming is a different idea than type tailoring. If you don’t believe me, ask one of my coauthors. ;) Unsurprisingly though, Racket has some of the best support for type tailoring.

[shawn_w]

No, having embedded dsls that aren't just treated as strings, but as integral parts of the system that get syntax checks etc. at compile time and that analyzers can understand.

[ashton314]

Right—that's the power and beauty of a good metaprogramming system is you can extend the language to meet your domain—not the other way around. Type tailoring is all about (ab)using metaprogramming to target the elaboration of surface syntax into something the type checker understands. So, the reason why it's sounding familiar is because type tailoring uses metaprogramming and targets eDSLs. Some of the stuff you're likely referring to (please send me a link with examples) probably is doing type tailoring.

The problem is that, until now, there hasn't been much awareness of the underlying thing going on here with types and metaprogramming. You might implement an eDSL with macros and get some nice type checking for free (I'm working on another project right now that does exactly this) but, with this type tailoring framework we're proposing, you might see ways that you can get more out of what you're doing by leveraging static information better and by programming the elaborator more cleverly. Does that help?

[fabianholzer]

Sounds like the Template Literal Types from Typescript on steroids.