Better API for BaudRate

[Carter Schonwald]

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 <allbery.b at gmail.com> 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 <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
>>
> _______________________________________________
> 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/20200514/71e3840f/attachment.html>