about summary refs log tree commit diff stats
path: root/tools/expand_string_handle
diff options
context:
space:
mode:
authorKartik K. Agaram <vc@akkartik.com>2021-05-31 07:29:33 -0700
committerKartik K. Agaram <vc@akkartik.com>2021-05-31 08:00:26 -0700
commite9d2f00edb5b537ba5a0b88f737af5e487653d3b (patch)
tree4cd5a3c7de4cc90a52263c1111fa28b6288d7172 /tools/expand_string_handle
parentf691782d113a98d5277e41a59268a937425f6aa2 (diff)
downloadmu-e9d2f00edb5b537ba5a0b88f737af5e487653d3b.tar.gz
multi-macroexpanding backquote != nested backquote
This was quite difficult to diagnose. The issue I noticed was that brline
had stopped working. All the bugs in previous commits were hiding the cause.
Once I cleaned them up, I realized the problem was that the `(,x0 ,y0)
was triggering the nested-backquote check. The fix was fairly straightforward
then (even though I didn't yet understand why). But how to write a test
for this? I spent some time trying to do so without defining a macro using
literal macros, before I realized:

  You can't call literal macros; we don't have first-class macros.

Trying to insert literal macro support just breaks everything because we
have no way to distinguish between a literal macro call and the stage in
macroexpand where a symbol has been replaced with its macro definition.

How do you explain stuff like this? I grow weary of Lisp.

There's still some issue in loading the entire definition of brline from
data.limg.
Diffstat (limited to 'tools/expand_string_handle')
0 files changed, 0 insertions, 0 deletions