Hoogle Search
Within LTS Haskell 24.34 (ghc-9.10.3)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
-
Dependent finite maps (partial dependent products) Provides a type called DMap which generalizes Data.Map.Map, allowing keys to specify the type of value that can be associated with them.
-
Martin Erwig's Functional Graph Library An inductive representation of manipulating graph data structures. Original website can be found at http://web.engr.oregonstate.edu/~erwig/fgl/haskell. Now without braces in cabal file.
-
Shared functionality between GHC and its boot libraries This library is shared between GHC, ghc-pkg, and other boot libraries. . A note about GHC.Unit.Database: it only deals with the subset of the package database that the compiler cares about: modules paths etc and not package metadata like description, authors etc. It is thus not a library interface to ghc-pkg and is *not* suitable for modifying GHC package databases. . The package database format and this library are constructed in such a way that while ghc-pkg depends on Cabal, the GHC library and program do not have to depend on Cabal.
-
Shared functionality between GHC and the @template-haskell@ library This library contains various bits shared between the ghc and template-haskell libraries. This package exists to ensure that template-haskell has a minimal set of transitive dependencies, since it is intended to be depended upon by user code.
-
Knowledge of GHC's installation directories Knowledge of GHC's installation directories
-
Gio bindings Bindings for Gio, autogenerated by haskell-gi.
-
Client library for the Redis datastore: supports full command set, pipelining. Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. This library is a Haskell client for the Redis datastore. Compared to other Haskell client libraries it has some advantages:
- Compatibility with Latest Stable Redis: Hedis is intended to be used with the latest stable version of Redis (currently 5.0). Most redis commands (http://redis.io/commands) are available as haskell functions, although MONITOR and SYNC are intentionally omitted. Additionally, a low-level API is exposed that makes it easy for the library user to implement further commands, such as new commands from an experimental Redis version.
- Automatic Optimal Pipelining: Commands are pipelined (http://redis.io/topics/pipelining) as much as possible without any work by the user. See http://informatikr.com/2012/redis-pipelining.html for a technical explanation of automatic optimal pipelining.
- Enforced Pub/Sub semantics: When subscribed to the Redis Pub/Sub server (http://redis.io/topics/pubsub), clients are not allowed to issue commands other than subscribing to or unsubscribing from channels. This library uses the type system to enforce the correct behavior.
- Connect via TCP or Unix Domain Socket: TCP sockets are the default way to connect to a Redis server. For connections to a server on the same machine, Unix domain sockets offer higher performance than the standard TCP connection.
-
microlens support for Reader/Writer/State from mtl This package contains functions (like view or +=) which work on MonadReader, MonadWriter, and MonadState from the mtl package. This package is a part of the microlens family; see the readme on Github.
-
Helper modules for FFI to BLAS and LAPACK Netlib is a collection of packages for efficient numeric linear algebra. Most prominent parts of Netlib are BLAS and LAPACK. These packages contain functions for matrix computations, solution of simultaneous linear equations and eigenvalue problems. This package provides definitions shared by the packages blas-ffi and lapack-ffi.
-
Network abstraction layer Network.Transport is a Network Abstraction Layer which provides the following high-level concepts: . * Nodes in the network are represented by EndPoints. These are heavyweight stateful objects. . * Each EndPoint has an EndPointAddress. . * Connections can be established from one EndPoint to another using the EndPointAddress of the remote end. . * The EndPointAddress can be serialised and sent over the network, whereas EndPoints and connections cannot. . * Connections between EndPoints are unidirectional and lightweight. . * Outgoing messages are sent via a Connection object that represents the sending end of the connection. . * Incoming messages for all of the incoming connections on an EndPoint are collected via a shared receive queue. . * In addition to incoming messages, EndPoints are notified of other Events such as new connections or broken connections. . This design was heavily influenced by the design of the Common Communication Interface (http://www.olcf.ornl.gov/center-projects/common-communication-interface). Important design goals are: . * Connections should be lightweight: it should be no problem to create thousands of connections between endpoints. . * Error handling is explicit: every function declares as part of its type which errors it can return (no exceptions are thrown) . * Error handling is "abstract": errors that originate from implementation specific problems (such as "no more sockets" in the TCP implementation) get mapped to generic errors ("insufficient resources") at the Transport level. . This package provides the generic interface only; you will probably also want to install at least one transport implementation (network-transport-*).