[[!meta title="REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ"]] [[!meta copyright="Copyright © 2023 Eduardo Ochs"]] [[!inline pages="internal(2023/info/repl-nav)" raw="yes"]] # REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ Eduardo Ochs - IRC: edrx, edrx , [[!inline pages="internal(2023/info/repl-before)" raw="yes"]] 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] [2] [3] [4] About the speaker: I am this person here: http://anggtwu.net/eepitch.html # Discussion ## Questions and answers - Q:if you had to summarize what you where trying to say in 3 sentences or less, what would you say? - A: Ouch! I would answer with a link... this one: ## Notes - Magic is good as long as you have the option to look behind the scenes when you want! :-)  Imagine if all code was assembly language. - hi edrx! =) great talk - A :I didn't create a git repo with the code yet because I don't have any idea if anyone would want to test it today... everything is made to be used with this interface, - Q: is the code available as a tarball perhaps? or not at all yet? - as I know very few people who use eev - and who already use that interface - I wanted to ask them if they'd be ok with installing some files in ~/LUA/ and ~/LATEX/, or if they really needed to use other directories, or what... the things that are to be installed in ~/LUA/ are in a tarball, but a few of the files require some files in ~/LATEX/. I'm preparing the LATEX/ directory of the tarball now and I'll announce it on the eev mailing list soon - Dealing with diagrams with Emacs is tricky. Having documented examples of that is nice and would be helpful - A: I _guess_ that the ideas that I presented would be easy to adapt to SVG diagrams, and to some packages that use Javascript to generate their diagram... but I don't want to write the code for SVG and for js diagrams all by myself. what do you use - or what have tried to use - to generate diagrams? - i've personally tried using a bunch of different tools but never found anything that fully clicked for me or was remotely pleasant to use. i guess 'draw.io' is decent, but something in Emacs would be awesome - do you think that musa's way to making emacs run javascript could work for draw.io? - hmm no clue tbh, worth trying to ask him. but i must say i'm not super enthused about embedding js in emacs - having tried most things (from exwm to org-protocol, to devtools debug protocol, and what not), I've converged on small personal extension that loads across browsers, locally, and stay connected with Emacs via the very useful emacs-websocket package, to interact both with the internal state of the browser (windows, tabs, etc.) and intra-page [[!inline pages="internal(2023/info/repl-after)" raw="yes"]] [[!inline pages="internal(2023/info/repl-nav)" raw="yes"]]