Better API for BaudRate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Better API for BaudRate

Travis Whitaker
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries