1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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"]]
|
