Post by @zzt@mas.to

I’ve done it, I’ve found a horrifying way to do sub-languages that’ll work with the emacs lisp reader and with other arbitrary readers:

(lang-quote brainfuck)
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
(lang-unquote)

if a sublanguage-enabled reader returns a form starting with lang-quote, pass the stream contents at the current symbol and ending at (lang-unquote) to the reader for that language, and return that as the value for the original read

lang-quote and lang-unquote can be any symbols as long as they aren’t expected to be read in any other context. actually (lang-unquote) can just be an empty function, it doesn’t need to mean anything special

if a non-lisp language wants to do sublanguages its expander just needs to return (lang-quote language). I could have the end token be configurable actually, huh

this is a truly horrifying hack but I kind of love it

6 Replies

4 Boosts

[object Object]

@zzt@mas.to 14 hr. ago

damn this almost works but any level of enclosing parentheses (including embedding the language in a variable, one of the use cases) causes the entire thing to get parsed as emacs lisp, including the sub-language, which isn’t ideal

potentially back to the drawing board but let me experiment, maybe there’s a recursive parse happening that I can hook into

[object Object]

@zzt@mas.to 13 hr. ago

there is a way to fix this that requires editing the original buffer during reading, which I’ve been avoiding resorting to

but it’s a less terrible edit with (lang-quote) than without

[object Object]

@zzt@mas.to 6 hr. ago

with the emacs lisp built-in reader I think the best I can do is a template-style form:

(lang-quote (defvar brainfuck-output expr) brainfuck)
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
(lang-unquote)

where the new argument is an s-expression that replaces the entire lang-quote/lang-unquote form and expr gets filled in with the expanded form of the brainfuck expression

I don’t entirely like it as it’s a bit clumsy and not that flexible, but it’ll work for a POC

for the real thing I might have to do an emacs lisp reader in emacs lisp, which would allow deriving other languages from that reader

[object Object]

@zzt@mas.to 6 hr. ago

also this works now

emacs hates it but it works

1 more reply

[object Object]

@zzt@mas.to 14 hr. ago

this works because the emacs lisp reader just reads one form and stops just in time for another reader to pick up its work at whichever position it stopped

[object Object]

@zzt@mas.to 14 hr. ago

my favorite type of code is horrors beyond comprehension