Title:
REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ
Abstract:
Many years ago, when I started programming, my dream was to write
games. I failed miserably in that, but I became fascinated by
languages, and I discovered Forth - that was perfect for writing
languages whose syntax was as simple as possible. Then I switched to
GNU/Linux and I had a series of favorite languages; at some point I
discovered Lua, that became not only my favorite language but also
my favorite tool for implementing other languages. One of the main
libraries of Lua is something called LPeg, that lets "people"
implement complex parsers in just a few lines of code using PEGs -
Parsing Expression Grammars.
I've put the "people" in the last paragraph between quotes
because for many years I wasn't included in the "people who can
implement complex parsers with LPeg"... lots of things in LPeg
didn't make sense to me, and I couldn't visualize how it worked.
Something was missing - some diagrams, maybe?
The main tool for drawing diagrams in LaTeX is something called
TikZ, that is HUGE - its manual has over 1000 pages. TikZ includes
lots of libraries and extensions, and each one of these libraries
and extensions extends TikZ's core language with some extra
constructs.
I don't know anyone - except for a handful of experts - who knows
what is the "core language" of Tikz, that lies, or that should lie,
below all these extensions... all of my friends who use TikZ are
just "users" of TikZ - they've learned some parts of TikZ by
starting with exemples, and by then modifying these examples mostly
by trial and error. In particular, no one among my friends knows how
styles in TikZ really work; styles are implemented using "keys",
that are hard to inspect from a running TeX - see [1] - and I
found the chapter on "key management" in the manual very hard to
understand. It feels as if something is missing from it... some
diagrams, maybe?
In my day job I am a mathematician. I work in a federal
university in Brazil, and besides teaching I do some research -
mostly in areas in which the papers and theses have lots of
diagrams, of many different kinds, and in which people use zillions
of different programs to draw their diagrams. Every time that I see
those diagrams I think "wow, I need to learn how to draw diagrams
like that!", but until a few months ago this seemed to be
impossible, or very hard, or very painful...
This presentation will be about a point in which all these ideas
intersect. I am the author of an Emacs package called eev, that
encourages using REPLs in a certain way; Lua can be used in several
different styles, and if we use it in a certain way that most people
hate - with lots of globals, and with an implementation of OO that
makes everything inspectable and modifiable - then it becomes very
REPL-friendly; there is an extension of LPeg called LPegRex ([2], [3]), that I found promising but hard to use, so I rewrote
some parts of it to make them more REPL-friendly, and to make it
print its ASTs in 2D ASCII art. The core of my presentation will be
about how I am using REPLs written in Lua to write grammars,
parsers, and tools to generate many kinds of diagrams, and how I am
using these diagrams to document both my own code and other people's
programs - the parts of them in which some diagrams seem to be
missing. My hope is that people will find these ideas easy to port
to other languages besides Lua, to other tools for generating
diagrams besides LaTeX - SVG, maybe? - and to other ways to use
REPLs in Emacs besides eev. Some ideas in this presentation were
inspired by the blog post [4].
1. https://tex.stackexchange.com/questions/663740/alternative-to-edef-c-pgfkeys-a
2. https://github.com/edubart/lpegrex
3. https://github.com/edubart/lpegrex/blob/main/parsers/lua.lua
4. https://ianthehenry.com/posts/my-kind-of-repl/
This ended up being a very strange presentation. Due to personal
problems I was only able to finish the programs that I wanted to
present two days before the EmacsConf, and I recorded the video
without rehearsing it much... and the video ended up being about
languages and tools that few Emacsers use, and that I use in unusual -
but very REPL-friendly - ways, and the rationale behind these
REPL-friendly ways.