Better API for BaudRate

[Brandon Allbery]

Technically the running kernel can support or not support some baud rates.
Practically this shouldn't happen, but it should probably be documented
that it can throw a synchronous exception (sigh, but that's a different
thread).

On Tue, May 12, 2020, 02:25 Travis Whitaker <pi.boy.travis at gmail.com> wrote:

> Hello fellow Haskellers,
>
> In my line of work I have the (mis)fortune of making extensive use of
> the POSIX TTY API. The System.Posix.Terminal module from the unix
> package is mostly fine for this, except for handling baud rates.
>
> The trouble is that POSIX stipulates the presence of a small set of
> baud rate options as CPP macros in the range 0 - 38400, but this is
> far too slow for any modern device. Linux, macOS, and likely other
> Unixes conditionally define many additional CPP macros for baud rates:
> Linux's termbits.h goes all the way up to 4000000.
>
> So, we know from CPP at compile time which baud rate values should
> work with the TTY syscalls. Given this, I'd propose a set of
> definitions for baud rates similar to what Ed Kmett uses in his "gl"
> package: represent baud rates as their C type, and use CPP to define
> bidirectional pattern synonyms for the present baud rate constants.
> This eliminates a key problem with the current API: baud rate code can
> fail at compile time (BaudRate constructors are conditionally present
> based on CPP) _or_ runtime (there are CPP-conditional partial
> functions on BaudRate in the API). With the pattern synonyms approach,
> all failures due to missing baud rate CPP definitions will occur at
> compile time, and total functions on baud rate must be defined in
> terms of a conversion to the underlying numeric type.
>
> There is a sketch of this technique here:
> https://github.com/haskell/unix/pull/145 I'm eager to hear others'
> thoughts on how the baud rate API might be improved.
>
> Travis Whitaker
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200512/2c29b842/attachment.html>