posix bindings.

This library provides a very thin wrapper around POSIX APIs. It can be compiled on any operating system that implements the standard as specified in IEEE Std 1003.1 faithfully. It has similar goals as the unix package, but its design differs in several areas: . * ByteArray and Addr are used pervasively. There is no use of String in this library. . * Functions do not throw errors. This library uses `IO (Either Errno a)` in places where unix would use `IO a`. . * The numeric types from Foreign.C.Types and System.Posix.Types are used in the type signatures of functions so that a haskell function's type signature matches its underlying POSIX equivalent exactly. . * Flags are newtypes over CInt (or whatever integral type matches the posix specification) rather than enumerations. The data constructors are exported, making the types extensible for operating system that have additional flags. . About a dozen other packages offers wrappers for some subset of the POSIX specification are strewn across hackage. They include `regex-posix`, `posix-paths`, `posix-timer`, `posix-socket`, `posix-filelock`, `posix-acl`, etc. This library differs from all off these in various ways. Here are some of the design guidelines followed here that distinguish this package from some or all of these others: . * Scope. Although this library does not include all APIs specified by POSIX, it welcomes as many of them as anyone is willing to implement. . * Monomorphization. Effectful functions in this library return their results in IO rather than using a type that involves MonadIO or MonadBaseControl. . * Typeclass avoidance. This library does not introduce new typeclasses. Overloading is eschewed in favor of providing multiple functions with distinct names. . * Minimality. Functions wrapping the POSIX APIs do little more than wrap the underlying functions. The major deviation here is that, when applicable, the wrappers allocate buffers are the underlying functions fill. This eschews C's characteristic buffer-passing in favor of the Haskell convention of allocating internally and returning. A more minor deviation is that for safe FFI calls, this library will perform additional work to ensure that only pinned byte arrays are handed over. . Unlike network, this sockets API in this library does not integrate sockets with GHC's event manager. This is geared toward an audience that understands how to use threadWaitRead and threadWaitWrite with unsafe FFI calls to avoid blocking the runtime.

posix-api

Objective

This library provides minimal bindings to system calls for POSIX-compliant operating systems. All functions follow these design decisions:

• String is not used anywhere. ByteArray (from primitive) is used for serialized data. It is also used in certain filesystem function variants used in contexts where the paths are only ever handed over to other filesystem functions. Addr (from primitive) is used for pointers to data whose type is unknown. Ptr is used for pointers to data whose type is known.
• Functions should not throw errors. This library uses IO (Either Errno a) in places where some libraries would use IO a.
• The numeric types from Foreign.C.Types and System.Posix.Types are used in the type signatures of functions so that a haskell function's type signature matches its underlying POSIX equivalent exactly.
• Flags are newtypes over CInt (or whatever integral type matches the posix specification) rather than enumerations. The data constructors are exported, making the types extensible for operating system that have additional flags.
• There is some platform-specific code in this library. POSIX-specified data structures do not have the same in-memory representation on all platforms. Consequently, some of the code to serialize data to its C-struct representation must be written differently on different platforms. This is seldom needed. A viable alternative would be using the FFI to perform this serialization. However, the approach of using per-platform haskell code lets the serialization code inline better.

Pull requests that add bindings to POSIX APIs in a way that agrees with these guidelines will be accepted. Unfortunately, there is some grey area when it comes to what a "minimal binding" to a function is. Discussion may sometimes be necessary to refine the guidelines.

Infelicities

This project currently includes some Linux-specific code. It in the the Linux.Socket. The plan is to eventually move the Linux.Socket module into its own library. Currently, a ton of POSIX APIs are missing. These should be included.