SIGPLAN Blog

This made me wonder if RLibm has been extended to doubles yet[0]. Sadly that doesn't seem to be the case. It's a floating point math library that always produces correct rounding results, but it is limited to 32-bit floats (and posits, for that matter). Interestingly, despite being the only library that always rounds correctly, it also claims to be faster than other libraries (at same bit-depth). I can recommend the papers, they're quite accessible and there is something very satisfying about the math tricks they came up with to build the polynomials. They do seem to have added more rounding modes though, which presumably makes the library more generally useful.[1] [0] https://people.cs.rutgers.edu/~sn349/rlibm/ [1] https://blog.sigplan.org/2022/04/28/one-polynomial-approximation-to-pr…

Here is a short (5 min) video explaining E-Graphs: https://www.youtube.com/watch?v=ap29SzDAzP There is also a longer (30 min) video that goes into details. I recommend watching them! Also consider this blogpost: https://blog.sigplan.org/2021/04/06/equality-saturation-with-egg/

There is also a part 0. [0] A part 2 will soon follow if I read it correctly. The author of these posts also has a talk on the same topic. [1] I tried posting the entire seminar series a couple of days ago but there wasn't much interest unfortunately. Maybe you'll find it interesting! [0] https://blog.sigplan.org/2020/11/17/functional-algorithm-design-part-0… [1] https://youtube.com/channel/UCiGOzKde1rlvzEB7J73gvrQ

> So.... this is just a fancy name for the advice "give your functions a name"? Not quite: "defunctionalization" is a name for replacing functions with not-functions (data structures). (And IMO it's the most unfancy name one can give to that activity, as the name literally just indicates "removing functions"... I can't think of a less fancy name for it: maybe "un-function-ize"? But that's pretty much the same as "defunctionalization".) BTW I recommend reading the 3 linked articles in this order: 1. https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… 2. http://www.pathsensitive.com/2019/07/the-best-refactoring-youve-never-… (with accompanying video) 3. https://www.gresearch.co.uk/article/defunctionalisation/ (this one actually shows how you can incrementally adopt this)

"Unityped" is informal, and inaccurate in a type theory context. The description you gave refers to the runtime/semantic domain, not to types in the type theory sense. I used "syntactic type" to underscore that formally, typing is a syntactic system that assigns types to terms, where terms are syntactic expressions. Because of that, it's usually redundant to include "syntactic". You'll typically see it used when it's being contrasted to some other less standard approach to typing, e.g.: https://blog.sigplan.org/2019/10/17/what-type-soundness-theorem-do-you…

It's the first I've heard of them. Looks like the research goes back to 1980, but good libraries seem fairly new? https://blog.sigplan.org/2021/04/06/equality-saturation-with-egg/

I came up with this idea one day after I remember a conversation I had. We were talking about how Kubernetes doesn't quite fit into LLM/AI workloads. I also thought about this article while working on this: https://blog.sigplan.org/2025/08/29/ai-models-need-a-virtual-machine/

> Do you think UB-as-feature is something that someone would honestly describe C or C++ as? Yes. That's how I describe it. That's also how Ralf Jung (long time Rust contributor and one of the main people behind Miri) describes UB in both Rust and C++ (although he says C++ overdoes it) [1] The thing I edited out of my comment was "motte and bailey fallacy" because after reflecting a bit I thought it was unfair. But now you're actually trying to retroactively reframe as a joke. [1] https://blog.sigplan.org/2021/11/18/undefined-behavior-deserves-a-bett…

Might as well just include everyone's games inside of everyone else's game as nested entities whose microstates determine the above games macrostates. This is very similar to Reflective Towers Of Interpreters: https://blog.sigplan.org/2021/08/12/reflective-towers-of-interpreters/

Exactly. Although, I would add that type level computations definitely can be used to perform useful metaprogramming tasks, such as embedding domain-specific languages or enforcing API protocols at compile time. I show some examples in my other papers. You can also check out my blog post: https://blog.sigplan.org/2021/03/02/fluent-api-practice-and-theory/

Consider the Enums simply as defunctionalized closures. https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… There are significant advantages to this sort of defunctionalization in a system like this. It is a bit more administratively at the point of enum definition, but the flexibility and simplification of the other parts of the program will be a win for almost any non-trivial UI application, not to mention the future-proofing it gives you.

This is a bit like defunctionalization: https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… It's basically replacing a function pointer with an enum. The kernel version is particularly simple, because the enum values don't have fields, they are a pure discriminant. Although I think the integritized function pointers aren't enum values or indices into the jump table, they're pointers into it. I think they could be indices; I'm not sure if there's a reason this is a bad idea.

That's a strange lisp... A few other strategies for solving this problem include something along the lines of the Small Clojure Interpreter (1) and Defunctionalization (2, 3) [1] https://github.com/borkdude/sci [2] https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… [3] https://www.cis.upenn.edu/~plclub/blog/2020-05-15-Defunctionalize-the-…

Emery Berger argues that the systems community should be doing exactly this -- improving infrastructure to run JS and Python workloads: https://blog.sigplan.org/2020/10/12/from-heavy-metal-to-irrational-exu… We need to incorporate JavaScript and Python workloads into our evaluations. There are already standard benchmark suites for JavaScript performance in the browser, and we can include applications written in node.js (server-side JavaScript), Python web servers, and more. This is where cycles are being spent today, and we need evaluation that matches modern workloads. For example, we should care less if a proposed mobile chip or compiler optimization slows down SPEC, and care more if it speeds up Python or JavaScript!

Yes and no - `doThing` itself is less inspectable, and it's sometimes helpful to separate the implementation from the instructions. (I wrote https://www.gresearch.co.uk/article/defunctionalisation/ ; the usual introduction is https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… .)

As part of the short list: * Swarat: https://blog.sigplan.org/2020/04/15/synthesizing-neurosymbolic-program… <- probably heaviest on the math side wrt PL people * Ras Bodik (Berkeley -> UW): esp. w/ Pedro Domingos and all the MSR collaborators (Sumit Gulwani, ...) <- a bit biased b/c I was in the group while at Berkeley; Ras + Dawn are crazy creative * Percy Liang (Stanford): Coming from the ML side and w/ a long-running interest here

This one might be a bit more approachable: https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… as originally shared by https://news.ycombinator.com/item?id=21916774

I have heard this said, mainly because some patterns can be made unnecessary with first-class functions and pattern matching. Closures are emulated with explicit objects, and the visitor pattern is equivalent to pattern matching. Something that's pretty interesting, though, is that it's a transform called defunctionalization. There's an article about it [1] that has been shared before on HN. One form of defunctionalization is the well-known transformation of a recursive function into one that uses an explicit stack. The thing is, I don't think defunctionalization (from the equivalent functional form) present in object-oriented languages is strictly worse. Defining things with explicit objects may sometimes be more understandable, and more extensible; for example, the command pattern could be implemented as a closure, but then you can't later add an "undo" method to it later. Here's an example where defunctionalization makes the code more readable, not less. Haskell has a difference list [0] data structure; the purpose of it is that you can concatenate two difference lists in constant time, and then turn it into one long normal linked list in O(n) time. This gives much better performance than concatenating lists directly all the time. It's a lot like a rope, except for lists, not strings, and it's immutable. But the code is somewhat cryptic; it makes use of partial application and stores the tree in terms of partially applied functions. The "Demystifying DList" [0]…

I've been teaching a compiler class for 5 years. My experience has been that writing and teaching to write compiler is more efficient using horizontal step rather than vertical steps. What I call vertical steps are lexing, parsing, typing, compiling, emitting output code. What I call horizontal steps are language features going through all the vertical steps. For example it is far better to start with a compiler for the "int language" (valid programs consist in a single integer and that's it), and then progressively add horizontal layers (features) to the language, being able to tests these new features each time. For example adding additions, then other binary operation, then multiple instructions, then variables and affectation, etc. Next fall I will try the backward approach in my course (still using horizontal steps for building the project, but teaching the vertical steps backward). I'm quite convinced it will work better since I read this article: https://blog.sigplan.org/2021/02/23/teaching-compilers-backward/

> A game written in Haskell or Scheme probably has a main loop implemented via recursion, but it's still called a main loop If such a 'main loop' is a single function which (a) dispatches to one of a bunch of 'handlers' then (b) calls itself recursively, I would still call it a 'main-loop anti-pattern'. More formally, it's likely to be in "defunctionalised" form https://blog.sigplan.org/2019/12/30/defunctionalization-everybody-does… The problem with such 'main loops', whether actual loops or self-recursive functions, is that control flow has to keep doubling-back to this 'central dispatcher'. In the case of actual 'main loops' this is often an unavoidable consequence of lacking tail-call elimination. In languages with tail-call elimination, we're just over-complicating the problem. > This sounds like a recipe for spaghetti. The control flow for a 'main loop' program goes like this: main function fooHandler barHandler | +------call-------+ | +-----return------+ | +------call---------------------+ | +-----return--------------------+ | ... If we have tail-call elimination, the handlers can just call the 'main loop' instead of returning (this is just a CPS transformation), e.g.: main function fooHandler main function barHandler main function | +----call--------+ …

> When you're a small startup, what matters is the expressiveness of your language, and the ability do do a lot of things very very quickly. Type safety, performance, readability, those things don't matter. You're just a bunch of engineers who know the whole codebase inside out, you're pretty certain of what you're doing. I'm not familiar with this use of the term "expressiveness". My understanding is that expressiveness (as per "On the expressive power of programming languages", Felleisen 1991 [0]) has to do with capabilities that a language has that separate it from another language. C is more expressive than Python in that it gives you direct access to memory management, whereas Python is more expressive than C in that it provides inheritance/OO. (These are just examples.) Type safety, performance, and readability are all wholly separate from expressiveness, I think. A language's type system and performance benchmarks have nothing to do with the expressive power of a language outright, and "readability" is entirely subjective to begin with. So: would you mind elaborating on what you mean, exactly, by "expressiveness of [a] language" here? --- In fact, most of what you (and the linked article) are talking about has to do with the dynamic/static spectrum, not this "wizarding/engineering" spectrum you've coined (though I do kind of like the idea of that for discussing development methodologies). The article is all about how the dynamically-typed nature of Python…

Cover topics around software development, math, programming languages, and academia: http://stuffwithstuff.com/ https://ericlippert.com/ http://thume.ca/archive.html https://medium.com/@mdwdotla https://faculty.washington.edu/ajko/posts https://computinged.wordpress.com/ https://blog.acolyer.org/ https://blog.sigplan.org/blog/ https://blog.paranoidcoding.com/ https://blog.regehr.org/ https://eli.thegreenplace.net/ https://benhoyt.com/writings/ https://www.hillelwayne.com/post/ https://web.eecs.utk.edu/~azh/blog.html https://www.johndcook.com/blog/ https://blog.stephenmarz.com/