by ashish01 on 7/17/24, 6:51 PM with 29 comments
by ashton314 on 7/17/24, 8:54 PM
- 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
by AstroJetson on 7/17/24, 8:07 PM
Some of the same articles, but with updates and added reader comments.
(I posted Amazon, but there is a ton on the used market)
by dang on 7/17/24, 7:43 PM
“Little Languages” by Jon Bentley (1986) [pdf] - https://news.ycombinator.com/item?id=17881705 - Aug 2018 (17 comments)
by posix_monad on 7/18/24, 3:22 PM
You need to create:
- Grammar, parser, compiler, interpreter (delete as appropriate)
- Editor plugins for nice syntax highlighting
- Language server
- Packages for common things
- Nice website (or no one will use it)
- etc...
So the pressure is always to shoe-horn a big existing language into you problem. Maybe you can build a nice library if your language has decent syntax (or little to no syntax). If you have an AST representation, you probably dump it to JSON etc.
I am curious if any projects are trying to make this easier.
by LangChinBob on 7/18/24, 12:04 PM
by davidw on 7/17/24, 10:37 PM
by swatson741 on 7/21/24, 6:44 AM
by rramadass on 7/18/24, 5:50 AM
by blirio on 7/17/24, 11:15 PM
It's like SQL <-> RelationDB and jq <-> NonRelationalDB