<div dir="ltr">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 :) )</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 7:39 AM Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020, 02:25 Travis Whitaker <<a href="mailto:pi.boy.travis@gmail.com" target="_blank">pi.boy.travis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello fellow Haskellers,<br>
<br>
In my line of work I have the (mis)fortune of making extensive use of<br>
the POSIX TTY API. The System.Posix.Terminal module from the unix<br>
package is mostly fine for this, except for handling baud rates.<br>
<br>
The trouble is that POSIX stipulates the presence of a small set of<br>
baud rate options as CPP macros in the range 0 - 38400, but this is<br>
far too slow for any modern device. Linux, macOS, and likely other<br>
Unixes conditionally define many additional CPP macros for baud rates:<br>
Linux's termbits.h goes all the way up to 4000000.<br>
<br>
So, we know from CPP at compile time which baud rate values should<br>
work with the TTY syscalls. Given this, I'd propose a set of<br>
definitions for baud rates similar to what Ed Kmett uses in his "gl"<br>
package: represent baud rates as their C type, and use CPP to define<br>
bidirectional pattern synonyms for the present baud rate constants.<br>
This eliminates a key problem with the current API: baud rate code can<br>
fail at compile time (BaudRate constructors are conditionally present<br>
based on CPP) _or_ runtime (there are CPP-conditional partial<br>
functions on BaudRate in the API). With the pattern synonyms approach,<br>
all failures due to missing baud rate CPP definitions will occur at<br>
compile time, and total functions on baud rate must be defined in<br>
terms of a conversion to the underlying numeric type.<br>
<br>
There is a sketch of this technique here:<br>
<a href="https://github.com/haskell/unix/pull/145" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/unix/pull/145</a> I'm eager to hear others'<br>
thoughts on how the baud rate API might be improved.<br>
<br>
Travis Whitaker<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>