Today I would like to discuss the Crafting Interpreters book by Robert Nystrom.
It’s a book about designing an interpreter for a dynamic programming language called Lox. Well, not exactly. It’s split into two parts - in the first is about crafting a tree-walking interpreter, and the second is about writing a complete bytecode VM.
Tags / clojure
In the previous post on the subject I’ve described how one can create a custom compilation mode for any language. In the Dynamically extracting filenames from compiler output section I’m talking about various issues with how Clojure reports problem locations. The main problem is when the problem is inside of a dependency, and be it your own library, or a third-party one it’s equally tedious to go and look into it because the dependency usually is a jar file somewhere in the ~/.
Recently, I decided to try the now inbuilt LSP client called Eglot. I’ve been using the lsp-mode package for some years and while I don’t have any problems with it, I decided to try the in-house solution. Though, I already tried Eglot in the past, and it didn’t work for me, due to some complications with the language I’ve tried to use it with.
After I explored asynchronous programming in my first naive implementation a few years ago, I was hooked on the idea of asynchronous communication in programs. Motivated to take this concept further I’ve created the fennel-async library that I’ve shown at FennelConf 2022. While this library works, and I’ve managed to write a simple socket-based REPL and integrate it into Emacs as an experiment, I wasn’t satisfied with the implementation.
Another post in the not-so-series about Emacs configuration. Today I will describe my configuration for managing the compilation-error-regexp-alist variable in a way that is meaningful for the current project I’m working on. Some time ago I faced a problem that the compilation-error-regexp-alist variable contains far too many entries for different languages by default.
I’ve been into clojure.core.async lately, and I like the overall design of this library - it’s simple and easy to understand. However, at work, we use manifold in our projects, mainly because it is supported by the aleph server, which was chosen because it can asynchronously read data coming from the client.
This is a follow-up to my previous post regarding the bug in the clojure.core.async/pipeline-async function.
As I’ve mentioned at the end of that post, I’ve submitted a patch to Ask Clojure that should fix the off by two error for the asynchronous pipeline.
Quite recently I’ve been working on my asynchronous programming library for Fennel, and fiddling with clojure.core.async at the same time for my other project. I’ve found an interesting function, called pipeline-async, which seemed to be a good fit for my task. Here’s the documentation for this function:
Recently I’ve stumped upon a Reddit thread about defining a function that you can call a limited amount of times in Rust, with compile-time check, and I wondered if I can make the same thing in Clojure.
Some time ago I ported most of Clojure’s core namespace to Fennel and made it into a library called fennel-cljlib. This was my first library for Fennel, so it wasn’t really great in terms of how it was implemented. While it was making Fennel more like Clojure syntax-wise, which I like, it wasn’t following Clojure’s semantics that well.