I've been playing with a little structured editor for postfix expressions: https://archive.org/details/akkartik-2min-2020-09-20 Inspirations: * LoGlo (https://loglo.app/2020-06-16) * Brief () Unlike these, however, this version tries to hew to two principles: * Show all the data (following @Joshua Horowitz; http://joshuahhh.com/projects/pane) * Minimize interaction (following Bret Victor; http://worrydream.com/MagicInk) This was my first attempt at structured editing, and the code is quite messy. This prototype also feels like a bit of a dead end; it's not clear how to scale it up past a single line. I'm looking forward to seeing how the code and concepts evolve.

I hadn't heard the term 'structured editor' before. But I guess its what I've been building 😉

Thanks! Suggestions for making it more obvious most appreciated. I'm not sure what the best way is to use color here..

I think I was confused on first glance because the stack grows 'up'. So admittedly, I didn't pay enough attention to it, but I think the 'pyramid' shape of the numbers didn't make sense to me. Maybe if the stack grew down: 12 3 6 + 12 12 12 21 3 3 6 Note that I also align the 3 with the 2, not the 1, as you have it in the video, which helps I think.....?

to no one’s surprise, i love this! i agree with @Chris Maughan about the alignment—it may be too hard to lay out in text mode but i’d also appreciate a dataflow notation for stack changes like: 3 6 + ; entered commands 3 6 — + 9 ; stack diagram 5 3 / 5 5

I'm feeling a bit stuck with this one. It's not clear to me how to scale this up to more than one line. Function definitions also seem challenging. I spent some time trying to wrestle with the classic problem of concatenative languages that refactoring is only easy for consecutive words. So any suggestions or collaboration most appreciated.

What about highlighting both numbers on top of the stack when you apply an operation to them? For example 5 & 4. I guess it could be generalized to a rule that highlighting all the values that change in the stack in the iteration or that are used by the next operation

@Daniel Garcia Interesting! Feels confusing to highlight things based on the future, but worth a try.

Yeah, maybe different highlight colors for the future and the present?

Here's one of the ideas I had to make extracting functions more natural. In general, LoGlo has me noticing how breaking up lines of postfix and giving the results names that future lines can use (starting from an empty stack) ends up quite close to Lisp prefix notation. But the transitions are still killing me.

extremely bad mockup in Numbers

The borders might be hard to do in a text only program, but I like that the stack has a symbol for showing a push to it. I'm not sure how I feel about having an operation that is happening in the next cycle of the stack shown in the past 🤔

i actually think @Daniel Garcia’s notation is the right direction for stack effect notation—and if you have a “stack effect” blank column alternating like i put above, you can have the program token first and then the stack effect with eg the entry symbol placed correctly in time. i know that sentence is hard to read. im heading out the door. my coat is on

A quick test on how the stack looks if it's aligned at the top. I feel html + css is a quick way to prototype the look of it, my really dirty and quick prototype -> https://codepen.io/pel-daniel/pen/eYZQNzb. I feel the push to stack looks better but the operations look more confusing

i can’t figure out how to save or share codepens without an account (sign up button deletes the edits to the codepen i made 🤦‍♂️ ) but here’s kind of what i’m talking about in terms of staggering. i realize now that I’m building an animation timeline. the idea is that when you type a token, it highlights the affected cells (or in the case of a piece of data to put on the stack, fades in, or highlights, or something—that’s how I’m interpreting the arrow now). when you press space, the final result of the stack operation animates. this is to me the most natural way to make transitions make sense

Without getting into animations, here's an implementation of @Daniel Garcia's suggestion to highlight words clobbered at the next time step. Code for this change: https://github.com/akkartik/mu/commit/022595a20a Code for my previous screenshot: https://github.com/akkartik/mu/commit/3dfebacf4c

could be more of a diff-inspired coloring

Oh interesting. Adding the insert before the delete.

like. the red part is “deleted from stack” and the green part is “added to stack”. so typing a “1” shows you the diff that the stack would look like with a 1 on it. and typing a plus shows you the stack diff of losing the top two elements and gaining a third

Oh, I see. I didn't register that the red outline meant the numbers didn't exist anymore.

the idea is that when you type “+” it shows you the preview of what would happen if you did a +, which you confirm by pressing space

Ah, I didn't realize that the two columns for each word denote some sort of animation.

(this may be off track for what youre going for here but one of the things I like about the uncoiled nature of concatenative languages is that you can look at the line as a stream of tokens instead of say an array of tokens. so then you can look at any typed line as almost like an input from a video game controller)

By 'animation' here, I meant that maybe you intend only one of the columns for each pair to be visible at any given time, with the second column replacing the first after hitting whitespace. But now I think I was wrong.

this is what i’m going for, and i’m taking advantage of the fact that whitespace is almost the only significant thing in forth, so it’s as much a time slice as the token, so then you get enough space to show change over time instead of just state at points in time

I like that picture as well. But I can't help feeling that the two columns aren't quite the same thing. There's two kinds of time on a single axis, which makes things confusing.

yeah i agree... i was trying to think of a way to show “just the changes” in one of the columns which is how i landed on the diff thing. idk. something in me feels like there simply are two different stages—before the word is invoked and after

That does look good.

wait... this might be a way of looking at words and numbers almost like messages that get sent to the stack at each step. which means you could start nesting stacks in the way you were talking about by indenting. but indenting feels coiled, so maybe not. i’ll see if i can scrawl another diagram

I really like how the stack is between the between the words, to me looks more clear how is the result of the previous "operation"

If you are concerned about scaling then you should definitely align from the top, as presumably the stack could be hundreds deep, but only the top few will matter each step. Daniel's latest one is my favourite but I would only extend the grey Operation boxes 1/2 or 1/3 to the left, and do a grey funnel down to the + sign

The little splashes of color really help I think 🙂 I don't mind so much which way the stack is when the 'top' of it is obvious. But my preference is still for it to grow downwards. The diff notation that @Garth Goldwater did is interesting; and would probably help when actually writing the code and debugging, but I don't think it helps as much with reading it.

(Aside: I love this thread! Seeing everyone sketching out possibilities and jamming on ideas together is exactly the sort of thing I hoped to see when I joined this community.)

@Jack Rusher I was thinking the same thing; great stuff 🙂

@Kartik Agaram have you seen Legible Mathematics? http://glench.com/LegibleMathematics/

Here is my take, based on @Chris Knott sketch and using more "graphical" representation than pure terminal-like characters. (side note: I made this mainly for fun and because this thread is inspiring, not sure it really adds to the discussion though...) (side not bis: I made this using Vue.js)

A small nit, but I'd remove or reduce the 'Stacks' text and align the stacks under the sequence (i.e. closer and slightly to the right). I like the arrows here.

Yes, the extra row isn't needed. But I feel it is useful because I see the inter-stack space as a visual representation of the action that make transform the stack at each step. For example, the first one visually explains that "from a stack with an 8, and the user entering 1, you move down the 8 and place the 1 above it". etc.

@ogadaki I really like what you've done there. The version in my mind's eye removes the Sequence and Stacks labels and puts the sequence items (dark grey on light grey) where the dark on white repetitions are, keeping the semantics of the arrows -- if that makes any sense?

Yes, you are right, I missed that! In fact I added the "second sequence" later, when I found it makes sense to have it there. But I should have removed the first sequence which was no more needed.

I also really like the visual of it @ogadaki. Can you share your code in codepen to play with it?

I used Glitch (first time for me, I wanted to try it out) and the project is there: https://glitch.com/~calico-chill-nutria All is in src/app.js, so I guess you can copy and use it anywhere you can use Vue.js Single File Component.

Here's a new version: * I indented the stacks as y'all suggested. That seemed like a no-brainer. * I made the stacks grow downward. I was resistant to this. Stacks should grow up. It didn't seem serious that the start of an expression may grow unboundedly far from its result. But then I noticed the same thing can happen to the final result. That got me to change my mind. * I'm experimenting with a random but deterministic color assignment for values on the stack. The idea is to get these nice diagonals to indicate values sliding down. I don't care to be super explicit about what the columns mean and so on. Even if it takes a few minutes or a verbal explanation initially, I believe it's easy to understand how operators work in postfix without needing the constant clutter of arrows. Just having this dash of color might, I hope, provide enough indication of what's going on. But tell me what y'all think.

I like the background blocks better, than the fonts with colors. You need to do the thing where you look at the luminance of the background color, and if it is greater than .5, use a black font; that will make it pop.

Thanks for the tip! Unfortunately I have no idea how to tell what a terminal's background color is. That's one of my open problems that might only be resolved when I drop the Linux kernel and escape sequences..

Aren't you setting the color for each character anyway? i.e. when you submit the number to the terminal , you can set foreground/background?

I just set a color index that can be 0-15 or 0-255 depending on the terminal. So far trying to stick with 16 colors for portability. But the palette is set by the terminal emulator. Still, I realized after my previous comment that I can probably hardcode some of those color codes to use a black foreground. So now I'm playing with a color meter and your formula 🙂

@Kartik Agaram The colours have known mappings, yeah, but it'll be hard to make this look as good as it could with that palette.

Does this look right? This is the first use case I've encountered for floating point, and now I'm starting to think again about what it would take to implement.

Yeah, hopefully you can see how much more readable the text is. Nice

I do! Thanks for pointing these things out. I'm visually unsophisticated.

a final note: i was wondering what the top-down stack notation reminded me of and i finally realized it’s a PEZ dispenser. weirdly google isn’t returning any good gifs so i guess this is just a fun fact for people familiar with kitschy US candy gimmicks

Surprised to have not seen one that looks like this:

checking my understanding: the lines track where the data ends up being consumed?

Underline the parts that combine, stick the result under the line. If you use straight lines rather than curvy ones, it looks like a pretty conventional tree, but the curvy ones keep it from getting deep. The green line shape, for instance, is going to be very common.

ohh interesting

(1) I think the curve the lines tell you more about the shape of data dependencies than a more regular reduction tree might. (2) I like to imagine non-strict evaluation of concatenative languages: start wherever (or everwhere) and reduce from there. Imagine a rewrite process per word. A literal

5

reduces to itself. An operator

+

looks to the left two words. If they are reduced, you can reduce; otherwise, wait for them.

this is interesting because i suspect that implementing that would look almost like taking the derivative of existing concatenative languages using rewrite rules, eg Cat/metaCat: https://web.archive.org/web/20140729145537/http://www.cat-language.com/intro.html