Hello, On 2022-02-11 at 02:30 +0100, Mario Lang <[email protected]> wrote: > Working on a Haskell binding for BrlAPI.
Excellent! > The following example works: [--] > main = withConnection "" ":0" $ \c -> do > dn <- getDriverName c > mi <- getModelIdentifier c > (x, _) <- getDisplaySize c > withTty c (Just 5) False $ \tty -> do [--] I'd make openConnection and enterTtyMode available too, not jsut the withSomeHandle-style functions. This way the application can discard the handles and create new ones at whatever point of the execution. This will also allow utilizing linear types in the future. > Reading the docs again, I am unsure if I want to mimick the low-level > API as much as I usually would. I think it would be better to have a > different type of handle for ttyMode operations. IOW, return some > handle from enterTtyMode and make writeText and friends use that. There are actually a few modes in which a BrlAPI connection can be. I would implement type classes for the common parts of these modes, and have a separate handle for each mode (at least basic, tty, raw and tty with raw keycodes). In addition I would export the low-level C functions from a separate module, in case somebody needs them, or the thick binding does not cover 100% of all possible API use cases. I'm very interested in this project. I try to push my Rust bindings to github soon, after some clean up. Possibly Rust and Haskell can share some ddesign decisions. I'm especially interested in how are you planning to handle the parameter API in a typesafe way, including the parameter state change callbacks. -- Aura _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
