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