Can application state type be a typeclass?

[amano-kenji]

If it is a typeclass, then I can replace a sum type with typeclass instances.

I haven't tried to make this happen, but is this possible?

[amano-kenji]

You can embed typeclass in an existential type, but I will have to try existential type with brick.

[amano-kenji]

I finally found the answer. The answer is to use a product type as the application state.

For example,

data State = {
  draw :: ...
, handleEvent :: ....
}

One mode can set application state to a different State for another mode in handleEvent.

With this, I can finally remove case statement.

[amano-kenji]

you cannot inspect the application state to know the application mode.

I don't know how I can debug haskell code. Can haskell debugger inspect variables hidden behind functions?

[jtdaugherty]

If I put draw and handleEvent into state, then state is handled by individual modes behind functions. State disappears from the global application state

Doing this means that your functions can only "mutate" state by passing it as arguments to subsequent calls, which is exactly what the state monad already does.

At any rate, you can certainly take whatever approach you like. I'm only trying to offer some advice for what I think will work out in the long run based on my experience both designing brick itself as well as writing large applications that use it.

[amano-kenji]

Obviously, this is just a way to prevent switching and pattern matching from growing huge. Brick wasn't designed to do this with typeclass or some sort of polymorphism, so it's awkward when I do it with a product type.

[jtdaugherty]

this is just a way to prevent switching and pattern matching from growing huge

I guess I'm not clear on why you think this is a problem. I don't think it's a problem, so I don't see it as something to be avoided.

Brick wasn't designed to do this with typeclass

That's right; I'm not even sure this makes any sense. At least if a type class was involved, I'm not sure how that would add any benefit. As for or some sort of polymorphism, that's what the s type is for in App. The polymorphism is already there.

One of the big drawbacks of using a type class for, say, existentially quantified types, is that they cause all kinds of trouble when you have to unpack constructors and convince the compiler that you have the right type in the right places. I've tried it and it doesn't go well, and it makes for software that is very hard to write, read, and maintain, let alone extend. This is essentially my response to the original question posed in this discussion item: the application state isn't incorporated via a type class because 1) there are no common operations on it that would make sense to put into a type class and 2) encapsulating the values of the application state via a type class would mean that Brick would need to use an existentially quantified type and that makes for very messy library design and a very hard-to-use API. Brick needs to carry around the application state, and if that's some s that satisfies a type class constraint, then the constraint has to be carried, too. That means wrapping it in a data type that externally loses type information (so the s goes away from the API). The problem then is that the type has to be recovered somehow and the compiler needs evidence that the recovered state type used in one spot obeys the same constraint as the type used in another spot. That means that the entire API gets infected by type class constraints that are at times very hard to deal with. I have seen libraries that do this and it usually ends in tears.

In your situation I suspect that you're attempting to optimize for the wrong things, and ultimately it will make your programming experience harder, not easier. That's something to think about: when you try to use a library in a particular way and that makes life harder, maybe that's because the library is not designed to be used that way for good reason. Trying to resist that and working around it usually just makes things harder.

[amano-kenji]

I didn't like seeing a huge case statement or a huge product type that contains every mode in one source file. So, that's an issue, but we haven't found a better design, yet.

I'm not going to let perfection be the enemy of good, so I will live with it for now.

[amano-kenji]

I accidentally stumbled upon a clean solution.

module Test (
  testNow
) where

-- optics-core
import Optics.Core
-- base
import GHC.Generics (Generic)

newtype Test s = Test {
  ok :: s
} deriving Generic

class TestClass s where
  pp :: s -> IO ()

newtype TestData = TestData String

instance TestClass TestData where
  pp (TestData s) = putStrLn s

testTest :: (Test s -> IO ()) -> Test s -> IO ()
testTest tf t = do
  tf t

hoho :: TestClass s =>  Test s -> IO ()
hoho t = do
  pp $ t ^. #ok

testNow :: IO ()
testNow = do
  testTest hoho $ Test $ TestData "ok"

In cabal repl

> import Test
> testNow
ok

You can pass TestClass s => Test s -> IO () to an argument that expects Test s -> IO (). Basically, haskell doesn't care whether you pass a function that has extra typeclass constraints to a function argument.

Thus, you can do something like

data AppState ui = AppState {
  uiState :: ui
, mode :: Mode
, timezone :: TimeZone
} deriving Generic

class UIState ui where
  draw :: ...
  handleEvent :: ...

drawApp :: UIState ui => AppState ui -> [Widget n]

handleAppEvent :: UIState ui => BrickEvent n e -> EventM n (AppState ui) ()

main :: IO ()
main = do
  defaultMain ... App { appDraw = drawApp, appHandleEvent = handleAppEvent } ...

Thus, I can use any number of typeclasses without changing brick. I don't know whether it is a good design, but it can work. Right? I think this is a new pattern.

[amano-kenji]

I realized that the above example doesn't allow replacing one typeclass instance with another.

Unless EventM n s a becomes EventM n s1 s2 a, EventM can't handle replacing one typeclass instance with another in the above example.

I can use existentially quantified typeclass constraint within my app state data type, but I'm still thinking of a way to do this without changing brick or using existential typeclass within application. For now, using existential typeclass in app state data type seems to be the only sane way.

[amano-kenji]

Even if I have EventM n s1 s2 a, different typeclasses used in a data type won't be aware of each other seamlessly.

Thus, sometimes, using existential typeclasses in my application state data type seems to be the right thing. This doesn't require any change to brick, and I can't think why it is going to be bad.