contificate

5 ms·

1.
by contificate 9mo ago
There's quite neat lexer and parser generators for Python that can ease the barrier to entry. For example, I've used PLY now and then for very small things. On the non-generated side, lexer creation is largely mechanical - even if
2.
by contificate 9mo ago
I agree. I've found that, for the languages I'm interesting in compiling (strict functional languages), a custom backend is desirable simply because LLVM isn't well suited for various things you might like to do when compilin
3.
by contificate 9mo ago
> Meanwhile, a compiler is an enormously complicated story. I don't intend to downplay the effort involved in creating a large project, but it's evident to me that there's a class of "better C" languages for whic
4.
by contificate 11mo ago
There's a neat paper where they implement basic blocks (in a control flow graph) as zippers ( https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf ). The neat part is that - due to how the host language works (mutation
5.
by contificate 2y ago
I sometimes write C recreationally. The real problem I have with it is that it's overly laborious for the boring parts (e.g. spelling out inductive datatypes). If you imagine that a large amount of writing a compiler (or similar) in C
6.
by contificate 2y ago
Nice. I'm always happy to see more accessible resources for compiler writers. --- As an aside: for displaying CFGs on the page, it would be very interesting to emit something somewhat dynamic. SVGs are always a good start, but there is
7.
by contificate 2y ago
I think it will introduce too many redundant phis, but I've never used it in practice - so I can only speculate. I'm not convinced DCE will clean maximal SSA up substantially. Even the classic Cytron et al algorithm must be combin
8.
by contificate 2y ago
On the topic of QBE, I've always felt that someone aiming to do the same scope of project ought to make their IR a syntactic subset of LLVM IR. If you do that, your test suite can involve invoking LLVM for a comparison. As for QBE itse
9.
by contificate 2y ago
Typical implementations of Lengauer-Tarjan are often taken verbatim from Andrew Appel's book and involve higher constant factors than alternative algorithms - such as Cooper et al's "engineered" version of the usual fixp
10.
by contificate 2y ago
I have a rather niche theory that many Hindley-Milner type inference tutorials written by Haskellers insist on teaching the error-prone, slow, details of algorithm W because otherwise the authors would need to commit to a way to do destruct
11.
by contificate 2y ago
My reading of the article is that the author has chosen to use "ANF" to describe a specific property of their IR that is not unique to ANF, whilst ignoring the fact that ANF (and variants of it) is strongly tied to the functional
12.
by contificate 2y ago
The author has mentioned ANF a few times but, from what I can tell, the likeness that they emphasise is really just the usual property of operands being atomic. This is a property used in many IRs, but I don't feel it's enough to
13.
by contificate 2y ago
Ah, I thought your username was familiar: you recommended Wadler's approach on a previous HN thread concerning my blog post about Pettersson/Maranget's algorithm ( https://news.ycombinator.com/item?id=39241776
14.
by contificate 2y ago
If we are talking about the context of a compiler, I agree: you should compile pattern matching to decision trees (DAGs), by way of something like Pettersson's algorithm. In my comment, I specified "in an interpreter", as I t
15.
by contificate 2y ago
It is worth noting that lots of applications of unification do not reify explicit substitutions in their implementations. You often see introductory type inference articles (usually focused on Hindley-Milner) use algorithm W, which uses a u
16.
by contificate 3y ago
Thank you very much! Your website's landing page is very clean.
17.
by contificate 3y ago
This is my blog, thanks for posting - never expected to see such engagement.
18.
by contificate 4y ago
Agreed, union-find is great. My favourite usage of it in practice is for solving first-order (syntactic) unification problems. Destructive unification by means of rewriting unbound variables to be links to other elements is a very pretty so
19.
by contificate 4y ago
I think the languages you selected in your final remark sum it up for me. If one is truly taken by functional programming, much of their mental model starts to revolve around algebraic (inductively defined) data types and structural recursi