CSE Machine: Function descriptions during print mode overlaps with frames

[ThatLi]

Descriptions for function objects displayed when print mode is on would result in overlaps, as pointed out by @Akshay-2007-1. This issue exists in the current version of Source Academy, which makes it difficult to make out the names declared in frames that were overlaid.

Example 1:

function foo(n) {
    let arr = [];
    let i = 0;
    while (i < n) {
        function bar() {
            return 3;
        }
        arr[i] = bar;
        i = i + 1;
    }
}
foo(3);

Example 2:

function foo() {
    function f(x) {
        return y => x + 3;
    }
    return f;
}
foo()(4);
foo()(5);

[martin-henz]

I think the same logic as in #3603 would apply here. The print button would be analogous and orthogonal to the clear button: It applies only to the current picture and permanently modifies the picture by switching to a white background and a display of all functions. The user can then save that picture, or press "clear". Pressing "clear" may mean that all dead nodes are permanently removed, and the white background and display of all functions is retained. Following this logic, the buttons "print", "clear" and "save" would:

• only apply to the current picture
• apply permanent (irreversible) operations on the current picture
• be accumulative: the result depends on which buttons have been pressed for that picture
• be idempotent: pressing the same button twice does not make a difference (for "save" you just get an identical copy of the picture)

I must admit that I'm not super confident whether we are on the right track on all of this. Feel free to discuss and express disagreement.

[Oofky]

I personally think the 'Print' button should remain as it currently is: a toggle that persists throughout different steps. This is because I don't see a significant incentive to change the 'Print' toggle into a one-time action button.

Why I don't see an incentive:

For the 'Clear Dead Frames' button, a one-time action button (that only applies to the current picture) is better because moving from one step to another can cause frames to shift whenever a new frame dies, which is confusing. Similarly, if the solution to this issue causes frames to move between steps in 'Print' mode, then the 'Print' mode toggle should be changed to a one-time action. This depends on the solution that the team has in mind.

However, from my perspective, the solution to this issue should likely not cause frames to move between steps. The naive solution that came to my mind is: For each frame with a function object binding, allocate an additional fixed space on the right side of the frame, specifically 27 characters worth of description space.

The current Source Academy already shifts frames to account for function objects:

20260225-1533-32.3672747.mp4

So it seems like maybe we only need to add some additional space to the existing implementation, but specifically for 'Print' mode only?

The fixed-coordinate layout system outlined in #3594 fixes the coordinate of frames to account for function objects as well:

20260225-1558-22.7011436.mp4

This is where I got the number 27 (23 + 4 characters from " ..."), in the class FnValue:

Here, the fixed-coordinate layout system would ensure that frames do not move between steps, so there does not seem to be a need to change the 'Print' toggle button into a 'Print' one-time action button?

In addition, I think it would be more convenient for users to toggle on (instead of clicking on each step) the 'Print' mode to view the entire execution process with a white background. This is because it may be the user's preferred view, as I see the 'Print' mode as a feature similar to dark mode/light mode, which is typically implemented as a toggle as well.

A small concern about the solution I suggested:

The solution I suggested somewhat conflicts with the idea of a fixed-coordinate layout system, as it suggests that the coordinates of frames and data objects will differ depending on the mode (normal or printable mode). But considering each mode independently, the rule of fixed-coordinates should be maintained. Also my idea is very naive, I did not look into the code closely.

[martin-henz]

OK, noted. If this "print mode" is a toggle option that changes the display permanently, we should move the button over to the left.

[Akshay-2007-1]

We have come up with a new implementation solution for this problem here #3627
Check it out!