mccJul 12, 2025

Note: I'm really unsure, with my hack quasiquote, what to call the "$" operator. It's not quasiquote— quasiquote is my "sub" function. I think "$" is the operator LISPs call "unquote", but I don't want to say that because I have an "unquote" function in my stdlib. I was gonna call it "pseudoquote", but I'm told LISP gives that word a special meaning too.

I am inclined to call $ "substitute". $ for $ubstitute. Might annoy the LISP heads, but much about this language will

https://mastodon.social/@mcc/114841768520556760

Show threadDionna Glaze, PhDJul 12, 2025
@mcc quote, unquote, and quasiquote are not functions though. They’re linguistic forms. Unquote and splicing unquote only have meaning in the syntactic extent of a quasiquote form. Quasiquote can be understood as a macro that expands into constructors of quotes. Only quote needs to be a built-in concept.
Show threadmcc
@drdeeglaze I don't have special forms, so quasiquote must be a function.
Jul 12, 2025 at 7:46pmTusky
Show threadDionna Glaze, PhDJul 12, 2025
@mcc do you use eval to get the unquoted expressions’ values? How do you pass along lexical context?
Show threadmccJul 12, 2025

@drdeeglaze eval is not strictly needed because lists are executable.

No closures yet :( it's a very minimal language. There is C++-like manual capturing when you promote a list to a function, though, so I can get what I need that way.

In essence, "sub" is a list->list transformation, and it only becomes a macro processor when combined with other features.

Show threadDionna Glaze, PhDJul 13, 2025
@mcc sounds like it’s going to have scope and compilation problems if you equate data with code always. “You want it when?” Describes a module system with explicit phase distinctions for functions to permit effective compilation.