please, share your favorite resources about programming languages and DSL design
I've collected a bunch of resources about this, notably in the little languages , notations and paradigms , programming languages and programming systems sections.
github.com/Little-Languages/reading-club/tree/main/topics
Notably:
Some of you have read (or at least listened to commentary on) "A Case for Feminism in Programming Language Design" by Felienne Hermans and Ari Schlesinger. It references Amy J. Ko’s Wordplay.
That led me to Ari Schlesinger’s PhD dissertation, "Addressing Computing's Discrimination Problem: A Framework for Anti-Discriminatory Computing". Chapter 6 – Exclusion and Inclusion in Programming Languages: A Case Study relates closely, but I enjoyed it overall.
I like Christopher Shank’s collection on little languages.
Lately, I have formed the opinion that we should become interested in “little networks”. programmingsimplicity.substack.com/p/little-networks?r=1egdky
2025-09-23
I agree with most of tonsky.me/blog/dsl
However, I think verbosity can be replaced/achieved/assisted by "IDE integration" to some degree, e.g. if IDE suggests would show, limit, and explain tokens I can use in curtain expression positions – tokens themselves could be short.
I learned to write compilers without building ASTs.
That means using “staged computation” (scan, parse, semantic analysis, allocation, code emission). Each stage gets its own little parser front end to direct its actions (today, this appears to be called “pattern matching”).
From that perspective it becomes straight-forward to build DSLs by mapping, in stages, input syntax to some existing programming language, i.e. using existing languages as “assemblers”.
CFG-based tools like YACC, make this kind of thinking difficult. Recursive descent code and tools, like S/SL (Syntax / Semantic Language) make this imaginable. New-fangled tools based on PEG - ohmjs.org - make this kind of thinking much, much easier.
I think of a stage in two parts - 1. parse, 2. rewrite. To this end, I use OhmJS for (1) and a little DSL for (2). I call the little DSL: RWR. I’ve combined these two parts into a tool I call T2T (text-to-text).
Super-simple examples can be seen in abc and abc to python and arith - stock arithmetic grammar emitting JS, Py, CL, WASM.
Big examples of creating a DSL can be seen in the PBP kernel project. This project uses PBP with some T2T components to create a new DSL called ‘rt’ and compiles the DSL code to Python and Javascript and Common Lisp.
/tangent/
What do you call "(building) AST" here?
Is it "Intermediate Representation with common structure for parses of all expressions"?
It seems to me, AST is just a result of "1. parse", not necessarily of the same shape/structure for each parse, whatever that looks like.
ohmjs emits parse tree (ohmjs.org/editor), you did not build it, but you use it.
"AST is just some IR" – makes it sound way less controversial.
I think, the more optimizations you need in output code, the more convenient/necessary it would be to have IR of format common across the expressions, to be able to operate not only on a list of opaque sibling nodes, but on several levels of the (AS)Tree at once (in a body of a single function). For transpiler use case, not having many things compilers usually have is even expected (what I saw in those repos looks more like transpiler than compiler, as in: all optimizations and not-1-to-1-input-to-output translations are outsourced to actual js/python/cl compilers).