#4316: Interactive "do" notation in GHCi
---------------------------------+------------------------------------------
Reporter: mitar | Owner:
Type: feature request | Status: new
Priority: normal | Component: GHCi
Version: 6.12.3 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by mitar):
Replying to [comment:4 vivian]:
> This would require GHCi to somehow know how to run arbitrary monads.
Hm, no, only how to evaluate do syntax. And if command there would have a
side effect (like putStrLn above) it would evaluate there and then.
> Some monads return {{{Value,State}}} (StateT), others return {{{Either
Error Value}}} (ErrorT), and so on.
Does it really matter what does monad return? Because this gets through
`evalStateT` to GHCi back and GHCi just prints that.
> The difference is between "prompting for more input," which relies only
on the original function call {{{flip evalStateT}}}, a 'syntactic'
operation, and multiple evaluations, a 'semantic' operation.
I agree. One is just easier to input do code, and the other is incremental
evaluation. As Haskell allows this (order of evaluation of pure code is
unspecified - so it can be also in order how you enter it and order of
evaluation of do block is also from top to bottom and it does not matter
in which monad you are) I think it should be possible.
But I am a newbie here so I will rest my case here. I just think that it
would be great to have more than syntactic improvement. For syntactic
part: we could then also have possibility to correct already written lines
and similar, before we "commit" the call. In incremental evaluation there
would not be possible to correct lines above (as they would be already
evaluated) but it would be much more useful for example to test some IO
with added state (what was my initial idea all about).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4316#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs