ap is:module

"Applicative Effects in Free Monads" Often times, the (\<*\>) operator can be more efficient than ap. Conventional free monads don't provide any means of modeling this. The free monad can be modified to make use of an underlying applicative. But it does require some laws, or else the (\<*\>) = ap law is broken. When interpreting this free monad with foldFree, the natural transformation must be an applicative homomorphism. An applicative homomorphism hm :: (Applicative f, Applicative g) => f x -> g x will satisfy these laws.

• hm (pure a) = pure a

• hm (f <*> a) = hm f <*> hm a

This is based on the "Applicative Effects in Free Monads" series of articles by Will Fancher

• Applicative Effects in Free Monads
• More on Applicative Effects in Free Monads

Given an applicative, the free monad transformer.

This file is generated based on X.org includes. It contains the keysyms for AP.

This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, this interface lacks the full power of the binding operation >>=, but

• it has more instances.
• it is sufficient for many uses, e.g. context-free parsing, or the Traversable class.
• instances can perform analysis of computations before they are executed, and thus produce shared optimizations.

This interface was introduced for parsers by Niklas Röjemo, because it admits more sharing than the monadic interface. The names here are mostly based on parsing work by Doaitse Swierstra. For more details, see Applicative Programming with Effects, by Conor McBride and Ross Paterson.

This module exports everything that you need to be able to create your own framework test provider. To create a provider you need to:

• Create an instance of the Testlike class
• Create an instance of the TestResultlike class
• Expose a function that lets people construct Test values using your new instances

This module exports everything that you need to be able to create your own test runner.

Module that deals with expression application in JavaScript. In some cases we rely on pre-generated functions that are bundled with the RTS (see rtsApply).

Middleware for establishing the root of the application. Many application need the ability to create URLs referring back to the application itself. For example: generate RSS feeds or sitemaps, giving users copy-paste links, or sending emails. In many cases, the approot can be determined correctly from the request headers. However, some things can prevent this, especially reverse proxies. This module provides multiple ways of configuring approot discovery, and functions for applications to get that approot. Approots are structured such that they can be prepended to a string such as foobar?baz=bin. For example, if your application is hosted on example.com using HTTPS, the approot would be https://example.com. Note the lack of a trailing slash.

This module corresponds to section 3.8.15 (Texture Application) of the OpenGL 2.1 specs.

Does a pandoc conversion based on command-line options.

This module contains reexports of Applicative and related functional. Additionally, it provides convenient combinators to work with Applicative.

TextShow instances for Const and ZipList. Since: 2

Information about an installed application and methods to launch it (with file arguments). GAppInfo and GAppLaunchContext are used for describing and launching applications installed on the system. As of GLib 2.20, URIs will always be converted to POSIX paths (using fileGetPath) when using appInfoLaunch even if the application requested an URI and not a POSIX path. For example for a desktop-file based application with the following Exec key:

Exec=totem %U

and a single URI, sftp://foo/file.avi, then /home/user/.gvfs/sftp on foo/file.avi will be passed. This will only work if a set of suitable GIO extensions (such as GVfs 2.26 compiled with FUSE support), is available and operational; if this is not the case, the URI will be passed unmodified to the application. Some URIs, such as mailto:, of course cannot be mapped to a POSIX path (in GVfs there’s no FUSE mount for it); such URIs will be passed unmodified to the application. Specifically for GVfs 2.26 and later, the POSIX URI will be mapped back to the GIO URI in the File constructors (since GVfs implements the GVfs extension point). As such, if the application needs to examine the URI, it needs to use fileGetUri or similar on File. In other words, an application cannot assume that the URI passed to e.g. fileNewForCommandlineArg is equal to the result of fileGetUri. The following snippet illustrates this:

c code

GFile *f;
char *uri;

file = g_file_new_for_commandline_arg (uri_from_commandline);

uri = g_file_get_uri (file);
strcmp (uri, uri_from_commandline) == 0;
g_free (uri);

if (g_file_has_uri_scheme (file, "cdda"))
{
// do something special with uri
}
g_object_unref (file);

This code will work when both cdda://sr0/Track 1.wav and /home/user/.gvfs/cdda on sr0/Track 1.wav is passed to the application. It should be noted that it’s generally not safe for applications to rely on the format of a particular URIs. Different launcher applications (e.g. file managers) may have different ideas of what a given URI means.

GAppInfoMonitor monitors application information for changes. GAppInfoMonitor is a very simple object used for monitoring the app info database for changes (newly installed or removed applications). Call appInfoMonitorGet to get a GAppInfoMonitor and connect to the AppInfoMonitor::changed signal. The signal will be emitted once when the app info database changes, and will not be emitted again until after the next call to appInfoGetAll or another g_app_info_*() function. This is because monitoring the app info database for changes is expensive. The following functions will re-arm the AppInfoMonitor::changed signal so it can be emitted again:

• appInfoGetAll
• appInfoGetAllForType
• appInfoGetDefaultForType
• appInfoGetFallbackForType
• appInfoGetRecommendedForType
• `g_desktop_app_info_get_implementations()`
• `g_desktop_app_info_new()`
• `g_desktop_app_info_new_from_filename()`
• `g_desktop_app_info_new_from_keyfile()`
• `g_desktop_app_info_search()`

The latter functions are available if using `GDesktopAppInfo` from gio-unix-2.0.pc (GIR namespace GioUnix-2.0). In the usual case, applications should try to make note of the change (doing things like invalidating caches) but not act on it. In particular, applications should avoid making calls to GAppInfo APIs in response to the change signal, deferring these until the time that the updated data is actually required. The exception to this case is when application information is actually being displayed on the screen (for example, during a search or when the list of all applications is shown). The reason for this is that changes to the list of installed applications often come in groups (like during system updates) and rescanning the list on every change is pointless and expensive. Since: 2.40

Integrating the launch with the launching application. This is used to handle for instance startup notification and launching the new application on the same screen as the launching window.