Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't show memory references in pretty-printed values #350

Open
xsebek opened this issue Jun 2, 2022 · 4 comments
Open

Don't show memory references in pretty-printed values #350

xsebek opened this issue Jun 2, 2022 · 4 comments
Labels
C-Moderate Effort Should take a moderate amount of time to address. G-CESK machine This issue has to do with the CESK machine (the Swarm language interpreter). L-Pretty-printing Pretty-printing ASTs or values into a string representation. S-Moderate The fix or feature would substantially improve user experience. Z-Feature A new feature to be added to the game. Z-User Experience This issue seeks to make the game more enjoyable to play.

Comments

@xsebek
Copy link
Member

xsebek commented Jun 2, 2022

Currently, we store sub-results as "memory cells" printed as @1. Ideally, players would never see them and there would always be a way to print a value so that it could be reconstructed.

Consider for example simple let, which is printed fine:

> let f = \i.i in f
\i. i : ∀ a2. a2 -> a2

But recursive let is printed with the memory cell:

> let fix = \f. f (fix f) in fix
let fix = @33 in \f. f (force fix f) : ∀ a6. (a6 -> a6) -> a6

Similarly using other definitions uses memory cells:

> def f = 1 end
> let g = \_.f in g
let f = @51 in \_. force f : ∀ a2. a2 -> int

We could keep the original definitions and their dependencies and print those so that after overwriting f we could still print g:

// PROPOSED BEHAVIOUR BELOW
> def f = 1 end
> def g = \_.f end
> g
\_.f : ∀ a0. a0 -> int
> def f = 2 end
> g
def f = 1 end
\_.f : ∀ a0. a0 -> int
@xsebek xsebek added Z-Feature A new feature to be added to the game. C-Moderate Effort Should take a moderate amount of time to address. S-Critical This is an issue that seriously affects playability or user experience. L-Pretty-printing Pretty-printing ASTs or values into a string representation. labels Jun 2, 2022
@xsebek
Copy link
Member Author

xsebek commented Jun 2, 2022

Hey @byorgey, do you think this would be possible generally or at least in common cases?

Maybe we could keep the Term and Env in VRef from VDelay?

@byorgey
Copy link
Member

byorgey commented Jun 2, 2022

Hmm, good question!

Ideally, players would never see them and there would always be a way to print a value so that it could be reconstructed.

Totally agree on this point. But off the top of my head I am not sure how difficult this would be. Intuitively it strikes me as one of those things that seems reasonable on the surface but hides some weird difficulties. I will give it some more thought and see if I can come up with a reasonable proposal.

@byorgey
Copy link
Member

byorgey commented Aug 7, 2022

So some of this is due to the way closures get printed. When we evaluate a TLam we generate a VClo (a closure containing the bound variable, the lambda body, and the environment). In order to pretty-print a value, we first convert it back into a Term using the valueToTerm function, which turns VClo into a TLet that represents the environment. However, in these specific examples, the let is unnecessary, because the let-bound thing is actually already in the ambient environment. I wonder if we could pass the existing top-level Env to valueToTerm, and have it omit let-binding things that are already in the top-level environment (with the same value!) as in the closure environment, when converting a VClo.

This would not eliminate memory references from ever showing up in pretty-printed terms (I think that is a tricky problem in general), but it would solve the def g example. However, it would not solve the let fix ... example.

I think the way to do this would be to add a Maybe Env argument to valueToTerm (we need Maybe since I think there are places we use valueToTerm where we don't have, or it would be awkward to obtain, an Env); if given an Env, when translating VClo, we will omit let bindings for variables in the closure environment with the same value as in the given Env. Then in the TUI.Controller.updateUI function, when printing the result of a REPL evaluation, we get the topValCtx (i.e. gameState . robotMap . ix 0 . robotContext . defVals) and pass it along to valueToTerm.

@byorgey
Copy link
Member

byorgey commented Nov 5, 2022

So in order to solve #7 I think we are definitely going to have to save definitions somewhere. So every time a def is executed (and maybe for let as well?), it will save both the source code of the definition as well as its value. Concretely, perhaps Env can store both. The thing I am still unsure about is how best to use this information for pretty-printing. Maybe it's good enough to (1) try pretty-printing the value of each binding, but (2) if something is bound to a VRef, then pretty-print its definition instead.

@byorgey byorgey added S-Moderate The fix or feature would substantially improve user experience. and removed S-Critical This is an issue that seriously affects playability or user experience. labels Jun 20, 2023
@byorgey byorgey changed the title Keep original definitions Don't show memory references in pretty-printed values Jun 20, 2023
@byorgey byorgey added Z-User Experience This issue seeks to make the game more enjoyable to play. G-CESK machine This issue has to do with the CESK machine (the Swarm language interpreter). labels Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Moderate Effort Should take a moderate amount of time to address. G-CESK machine This issue has to do with the CESK machine (the Swarm language interpreter). L-Pretty-printing Pretty-printing ASTs or values into a string representation. S-Moderate The fix or feature would substantially improve user experience. Z-Feature A new feature to be added to the game. Z-User Experience This issue seeks to make the game more enjoyable to play.
Projects
None yet
Development

No branches or pull requests

2 participants