-
Notifications
You must be signed in to change notification settings - Fork 165
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
halt
doesn't act like mzero
#23
Comments
Also, for what it's worth, I've had to define my own newtype EventM' a = EventM' (EventM a)
deriving (Functor, Applicative, Monad) because |
I've checked in some changes that address your second comment (making As for the first bit: I don't know anything about the Without more information I don't think I can embark on a refactoring. I'm happy to consider patches if you have ideas on how to implement this. |
I haven't looked at the internals at all, but an API that seems more natural might be something like data EventF a where
Halt :: EventF a
Suspend :: IO s -> (s -> a) -> EventF a
instance Functor EventF where ...
newtype EventM a = FreeT EventF (ReaderT (Map Name Viewport) (StateT EventState IO)) a
deriving (Functor, Applicative, Monad, MonadFree EventF, ...)
continue :: s -> EventM s
continue s = pure s
halt :: EventM a
halt = liftF Halt
suspend :: IO s -> EventM s
suspend action = liftF (Suspend action id)
-----
appHandleEvent :: s -> e -> EventM s
defaultMain :: App s e -> s -> IO () |
Thanks for writing that up! |
Ah, it was just a suggestion to allow you to move the Alternatively - you could perhaps expose the |
Here's a brick/auto adapter module from some work on a reddit client if you want to take a look. It's a bit kludgy and likely going to change eventually. https://github.com/mitchellwrosen/reddit-cli/blob/master/src/Brick/Auto.hs |
I'd like to avoid exposing the internals of Here's some extra context: my intention with the existing flow control API was to provide a mechanism for (only) the top-level event handler with the expectation that details about how to manage and compose event handling and state mutation would be a matter of doing pure operations rather than building up a library of Thanks for linking to that demo module! That helps illuminate what you're dealing with in the auto/brick interaction. I guess if it were me doing it (again, speaking from a position of ignorance on auto), going on what I said above, I wouldn't write the |
Makes sense, and I'm definitely exploring this "imperative-ish" game-loop type world myself for the first time in Haskell. In fact, looking back over my code, I'm not yet even using For understanding |
Since it's been a while on this issue: is this a show-stopping problem for anything you need to do? If not, I'd like to close this since I'm not inclined to make the change. I looked into |
Nope, it's not a show stopper by any means. |
Hi, I've been playing around with
brick
a bit and I've noticed thathalt
doesn't behave likemzero
. I'd like to write code that looks something like:This is actually a somewhat larger problem for me than just
when
vs.if-then-else
: I'd like to write composable, locally stateful event handlers usingauto
or similar, and step them forward in the top-level event handler them. However, currently I have no way of "inspecting" the return type of a handler (Next MyState
) to see if indeed I should halt or continue.I can easily work around this by defining my own ADT that encodes how to proceed, but it would essentially be almost identical to what already exists: either
Continue
orHalt
.Does this make sense? Thanks!
The text was updated successfully, but these errors were encountered: