Update on my text-mode postfix language and its li...
# two-minute-week
k
Update on my text-mode postfix language and its live-updating environment, all built up from x86 machine code: https://archive.org/details/akkartik-2min-2020-10-10 Previous episode: https://futureofcoding.slack.com/archives/C0120A3L30R/p1601191514009500 Main project page: https://github.com/akkartik/mu
❤️ 10
j
Keeps getting better, despite the "ghastly code" 🙂
❤️ 2
r
I really like the "ghastly code" comment. One question, maybe I missed it in a previous video but what do you mean by a "whole new stack" for each function call? Is it really a whole new stack under the hood or just a logical stack for visualization?
k
It does use a whole new stack. Though the distinction with "just visualization" is kinda moot when there are no side effects. Evaluation is a tiny part of visualization here, and evaluation often happens over and over again for a single rendering of the screen. Either way, there's no way for a function to access the (caller's) stack below the args it declares.
g
love the visualization! checking my understanding about intended semantics: if i defined a function as
x y myFunc: x y + 4 x *;
would it pull two values off the stack, with the x getting the top value and y getting the one below it? also (tricky question): any thoughts on recursion?
k
I haven't really used multiple args yet, so not sure if I've done it right. But my thought is that arg order should match calls. The function definition
x y myFunc
should map to a call like
3 4 myFunc
with
x
getting
3
and
y
getting
4
. Perhaps I'm missing something, but I don't think there's anything tricky about recursion! A recursive call is just a function call like any other, and the visualization metaphor here should uncoil it just like any other call. I don't have conditionals or quotes yet, so all recursion at the moment would be infinite. So it's not very useful at the moment.
One concern I have with this whole approach is something I've chatted with @Ivan Reese about before and something visible in the screenshot above: lots of name-punning. Different parts of a single (expanded) line may have very different behavior attached to the same name (here
x
).
g
thanks, that’s helpful clarification! i guess the difference in argument order depends on whether the function definition metaphor applies to the stack or the tokens you’re passing to the interpreter (if that makes sense). like 3 4 myFunc is either a series of stack instructions or a macro defining how to interpret the previous two tokens. not sure what i thought would be tricky about recursion—just can be tricky in general for UI i wonder if the name-punning issue can be resolved a bit further in UX. may have some messy sketch ideas about that
❤️ 1
k
One potential argument here is that the punning is ok, because you can just accept what the name turns into at each point, since you are freed from having to compute it. I don't know if that's a valid argument, though..
r
It occurs to me that this is very much like FORTH. FORTH avoids name punning by not naming the args in anything other than comments and just assuming there is a thing on the stack and my operation does this to it. That said, you can't do arg checking or any sort of typing in that manner.
I'm not sure how anything with a name scoped to a function can avoid name punning. It would have to be purely positional which would be very hard to read for humans.
👍 1