Skip to content
New issue

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

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

Already on GitHub? # to your account

Codelens eval should not interact with IO #461

Open
podocarp opened this issue Oct 3, 2020 · 3 comments
Open

Codelens eval should not interact with IO #461

podocarp opened this issue Oct 3, 2020 · 3 comments

Comments

@podocarp
Copy link

podocarp commented Oct 3, 2020

Subject of the issue

-- >>> getChar actually returns a value. It seems to be reading the characters from the link between the server and editor. However it does not seem to cause any crashes or ruin the link, on my editor at least. putStr etc. might also possibly be doing something unexpected although it does not seem to produce any noticeable effects on the editor.

Your environment

neovim 4.4, coc.nvim.

The codelens eval should perhaps perform some pre-processing and get rid of any IO first, just to be safe.

@googleson78
Copy link
Contributor

Perhaps std{in,err,out} can be redirected or something, but I think it can still be useful to have IO in examples (e.g. IORefs/MVars)

@jneira jneira added the type: enhancement New feature or request label Oct 5, 2020
@jneira
Copy link
Member

jneira commented Oct 5, 2020

@podocarp do you agree that handling std would be enough to make safe io calls?

@jneira jneira added status: needs info Not actionable, because there's missing information component: hls-eval-plugin labels Oct 5, 2020
@podocarp
Copy link
Author

Sorry, I'm not an expert in Haskell so I'm the wrong person to be asking. However handling it still sounds like a good idea. I would think that things like getLine however would have to be blocked altogether because it makes no sense in the first place.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants