could be more of a diff-inspired coloring

with like a “preview” or delta for each step

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)

this you could do without any animation—except as you type you would need to update the cell

so like this view would be the view after youve typed 1 2 3 4 5 + *. it’s a timeline of every event

like forth delimits tokens with whitespace, so without an EOF, newline, or space, it hasn’t finished processing the token

so you can interpret space, newline, and end of file as confirming that you want an action on the stack

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

but that’s right i don’t think i’d collapse it. the arrows i drew before and the diff view from more recently both attempt to indicate which items on the stack are being affected. i think you could use animation and cursor movement to do the same thing but my impression was that you were looking to avoid animation and also show all the steps

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

oh maybe it should look like this (not at computer): where the data is just interleaved between the tokens

sorry the weird boxes and underlines didn’t help

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"

the box around the top of the stack still doesn't make clear that is linked to the operation to the right

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 most generic notation I can think of is that at each step of the stack, put a little "incoming" icon for everything that's new that step, and "outgoing" for everything that's consumed that step

Possibly clearer with brackets (looks crap because I did them afterwards)

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/

Kartik Agaram or REPLugger? https://www.youtube.com/watch?v=F8p5bj01UWk&feature=youtu.be

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.

i.e. you don't need the extra row of symbols over the Stacks; you could just draw arrows between the sequence entries and their stack tops.

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.

Nicolas Decoster 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 Nicolas Decoster. 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.

Here's an alternative with background rather than foreground color.

Stress-testing width/margin computations.

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.

Luminance I use: (0.2126R + 0.7152G + 0.0722*B)

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 🙂

Are R/G/B above normalized between 0 and 1?

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

https://m.youtube.com/watch?v=YIAN6eKltsA here’s a video of someone preparing a program

relevant illustration from Starting Forth of a skyscraper-sized PEZ mechanism being loaded by a human and unloaded by machine

Surprised to have not seen one that looks like this:

Of course around this point, I start thinking in 2D, and we all know where that leads. What I find most compelling about LoGlo potentially is the idea of being between plain concatinative and freestyle node-and-edge layout.

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

i actually can’t stop thinking about the @William Taysom visualization. not sure what it means. i feel like if you did a slow border-radius grow on it you’d end up with tetris pieces

(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

also: http://nsl.com/papers/rewritejoy.html

actually, i think that reduction process might be how rebol/red works, just left-to-right instead of right-to-left

For Ixi lang in particular, I want to have highlights/effects on patterns that have been mutated too.

One of the goals of my project is to give the user a deeper understanding of how the text connects with the music. I want to enable that debug moment where you think 'where is that occasional note I can hear coming from - ah, yes, it's that pattern there' . So this is just the start of what I want to do.

I love where this project is going! 🙂

what do you use for the text editor, some parts of neovim?

Hi Mariano Guerra, the text editor is my own thing; I talk about it in some of my updates. You can see the project here: https://github.com/Rezonality/zep. There is a video overview too.

I built the editor to solve some of the problems you see here; since it needs embedded widgets, adornments, etc.

dragging and dropping formulas and parts of formulas is really satisfying

was a user request, he had this formula and wanted to use it elsewhere without creating it again.

that was created before dictionaries, but the feature was nice so I implemented it anyway

well, it can't use dictionaries until I add support for ranges on them...

The basket feature reminds me the backpack in Scratch. Very useful, I like it!

Why the function definition is 2 x *, but when expanded it's x 2 *?

My mistake. The left side is just a mock-up. Edit: now fixed by https://github.com/akkartik/mu/commit/7258083c6

This morning the suspicion returns that this is a dead end. When I designed expanding function calls I tried to support multiple levels (calls within calls). It doesn't work yet, of course. The cursor doesn't enter call bodies yet. I could make it work, but then what would editing call bodies mean? I could disallow it, but that restriction could also be confusing..

In case it isn't obvious, I'm not a designer. This prototype is taking me out of my comfort zone far more than all of Mu before. So comments and suggestions most appreciated.

i really like this and i hope you keep exploring! one expectation i might have is that when you expand the call stack and put your cursor in it you’re editing the function definition rather than the dynamic call—maybe indicated by something like

2*: x |2| * //pipes represent cursor

3 ``|``2``|`` *

and then editing the function would ask whether you want to make a new function or edit the old one. that may be way too complicated, though

Really cool Kartik Agaram. My hunch would be to try different layouts, for example a horizontal representation of the stack. My idea comes from thinking how would it look with a data type like a string, that the 'values' are longer than 1 character.

Indeed. I have some sketches where string literals would turn into little editors with wrapping. But rotating is also worth trying.

One idea I got experimenting with structural editors is that you can use pretty-printing algorithms to layout code. Now I don't know how to write a good pretty-printer for a stack-based language, but I hope that you can figure that out. (got the idea from https://molikto.github.io/posts/06-growing-a-structural-editor-02.html)

killer quote from that article putting to words an intuition i’ve been grappling with

I would make it so that the expanded function definition is rendered differently, to make it obvious it is read only. The there are two ways to edit;

• Jump to function definition which opens the function definition in the left pane, where you edit it (with variable names). Your edits are immediately reflected/duplicated in the expanded definition, this stack with real values. Because your cursor is duplicated, the user may well be looking at the right pane, but it should be obvious this is not what's "really" happening.
• You can "dump" the function definition into your main program. The definition shifts up to be in line with normal code. Edits do not affect the actual function definition.

(edit to point out this is a variation on Garth's idea)