Re: Better API for BaudRate

its definitely the case that a lot of system apis that we've historically represented as sum types are better (in general) represented as Pattern Synonyms over the underlying value rep that mirrors the c api (i'm not sure if i'm saying this precisely correctly, mind you :) ) On Tue, May 12, 2020 at 7:39 AM Brandon Allbery wrote:

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries