In my previous blog post I presented how I had come up with an embedded domain-specific language for creating web pages in my custom static site generator. I also mentioned the concept of “templates” in passing. Of course it was only logical to follow the page DSL up with a custom template DSL to smooth over the code duplication and pattern repetition.
I got bitten by the Lisp bug recently again, and so I decided to clean up an ugly wart in my static site generator which I use for generating the Workshop. The goal was to create an embedded domain-specific language (DSL) for defining web pages.
When I was still researching this fabled obscure language called Lisp one thing people kept saying about it is that “Lisp is a programmable programming language”, but I could never figure out what they meant by that. It sounds like a smug buzzword or like a gimmick from an academic toy language. Lisp programmers have gotten so used to metaprogramming in Lisp that they seem to forget that it is either an entirely alien concept to people, or something people have been burned by too often (like every C programmer).
Vim has good support for Scheme, but the problem with Scheme is that every implementation adds its own features to the language. My guile.vim plugin aims to improve support for GNU Guile by augmenting these settings. It can attempt to detect when a Scheme file is Guile-specific and it adds syntax highlighting for Guile-specific forms.
When I wrote guile-messagepack I needed an object to represent the
nilvalue, which embodies the concept of "nothingness" or "no value" in MessagePack. None of the existing objects like
'()were adequate, so I decided to make a new one:
nothing. It does not make sense for there to be multiple instance of
nothing, so it had to be a singleton. In this blog post I will describe a way of creating such a singleton.
I have written a Common Lisp completion source for NCM2, built upon Vlime. It provides asynchronous Common Lisp completion and should work in both Vim and Neovim, depending on how well NCM2 and Vlime themselves work.
In the previous article we have seen how to pack an object, this time we will see how to unpack it again on the receiving end.
In this part of the series I want to go into how to pack data to bytes in MessagePack. We will see how to dynamically dispatch on type and how to pack a selection of particular types.
When I originally set out to write MsgPack.rkt, a Racket implementation of the MessagePack protocol, I had a hard time wrapping my mind around where to begin. I had no experience in writing a serialisation library, and reading the source code of existing implementations only revealed the what, but not the why. This is why I'm starting this short mini-series of blog posts to provide a commentary on my implementation. I hope that it will serve other people who are looking for a starting point to their own implementations.