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

Is it possible to Implement a Cyber repl #76

Open
maxmcd opened this issue Jan 5, 2024 · 3 comments
Open

Is it possible to Implement a Cyber repl #76

maxmcd opened this issue Jan 5, 2024 · 3 comments

Comments

@maxmcd
Copy link

maxmcd commented Jan 5, 2024

Hello. Is it possible to implement a cyber repl? I am attempting to do so with the wasm-web build and I (understandably) cannot get values to persist in memory between eval runs. Is there any way to get this kind of thing working with cyber?

I'm playing around with some cyber/wasm, very hobby/hacking stuff, so not important.

@fubark
Copy link
Owner

fubark commented Jan 6, 2024

Currently the only way to persist vars is to bind a Map object created by the host which continues to persist across evals (it rebinds the map object everytime). Here's a test that demonstrates this:

test "Multiple evals persisting state." {

But you might want something like Python, Lua, etc. where you can freely use variables without declaring them. Those languages are purely dynamic and have a global variable scope so it works well by default. One way to achieve the same effect in Cyber is to recompile an object method for each eval. This object type would contain a Map field and implement the magic method ($missingField, which doesn't exist atm.) Since methods allow you to reference members without an explicit self it would be emulating a global variable scope. This hasn't been implemented yet but it should work in theory.

@fubark
Copy link
Owner

fubark commented Jan 6, 2024

Just had another idea... We could also expose an API to get all the static vars and increase their reference count by 1 and manage them so they aren't cleaned up for the next eval. Local vars would still be tricky to persist, but there could be a transpile step where var a = 123 could be replaced with var .a = 123 (the new syntax that will replace Root.a).

@maxmcd
Copy link
Author

maxmcd commented Jan 7, 2024

Ah nice, thank you for linking to a test/example. The ergonomics of seeing the global values against the imported map should actually work well for my needs.

Although yeah, would not work for a repl. The reference count trick def seems interesting. I definitely like the new .a syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants