Better API for BaudRate

Travis Whitaker pi.boy.travis at gmail.com
Tue May 12 06:25:24 UTC 2020


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


More information about the Libraries mailing list