[BRLTTY] BrlAPI for Haskell

[Mario Lang]

Aura Kelloniemi <kaura.dev at sange.fi> writes:

> Hello,
>
> On 2022-02-11 at 02:30 +0100, Mario Lang <mlang at blind.guru> 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.

They are available.  In fact, withConnection uses
openConnection/closeConnection to do its work.  Same for
withTty, which uses enterTtyMode/leaveTtyMode.  The with-style functions
are just a higher level idiom which made the basic example more concise.

>  > 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).

I think the common operations can still use the initial handle.
Typeclasses are neat, but rather questionable without any underlying laws.

> 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.

Hmm, good point.  The FII is already in a separate module, but I am
currently leaning towards not exporting that.

> 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.

While Rust and Haskell seem to be compared a lot lately, I personally
dont see the commonalities.  There is laziness, which can be useful but
also an unexpected beast.  And of course there is purity, which Rust
doesn't really have to care about.  The safety Rust brings you mostly comes
from borrowing.  The functional features of Rust are mostly syntactic sugar to me.
True, the iterator API and slightly more expression-oriented syntax
makes it feel like something one might have seen in more functional
languages.  But to me, Rust is still a fancy C with better compile-time checking.

> I'm especially interested in how are you planning to handle the
> parameter API in a typesafe way, including the parameter state change
> callbacks.

Frankyl, one step at a time.  I have no full laid out plan on how to do
the complete bindings yet.

-- 
CYa,
  ⡍⠁⠗⠊⠕