diff options
Diffstat (limited to '2023/talks/repl.md')
| -rw-r--r-- | 2023/talks/repl.md | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/2023/talks/repl.md b/2023/talks/repl.md new file mode 100644 index 00000000..bd0c01f9 --- /dev/null +++ b/2023/talks/repl.md @@ -0,0 +1,116 @@ +[[!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"]] + +<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing --> +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ +Eduardo Ochs - IRC: edrx, edrx <http://anggtwu.net/>, <mailto:eduardoochs@gmail.com> + +[[!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 +<span class="underline">need</span> 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/> + +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: + <http://anggtwu.net/eev-for-longtime-emacs-users.html#summarize-in-one-paragraph> + +## 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, <http://anggtwu.net/eepitch.html> + +- 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"]] + + |