| import Foundation | |
| import UIKit | |
| import PlaygroundSupport | |
| // -------------------------------------------------------------------------------- | |
| // MARK: - operators | |
| // -------------------------------------------------------------------------------- | |
| precedencegroup MonoidComposePrecedence { | |
| associativity: left higherThan: AssignmentPrecedence lowerThan: AdditionPrecedence |
| // This example shows how higher-kinded types can be emulated in Swift today. | |
| // It acheives correct typing at the cost of some boilerplate, manual lifting and an existential representation. | |
| // The technique below was directly inspired by the paper Lightweight Higher-Kinded Polymorphism | |
| // by Jeremy Yallop and Leo White found at http://ocamllabs.io/higher/lightweight-higher-kinded-polymorphism.pdf | |
| /// `ConstructorTag` represents a type constructor. | |
| /// `Argument` represents an argument to the type constructor. | |
| struct Apply<ConstructorTag, Argument> { | |
| /// An existential containing a value of `Constructor<Argument>` | |
| /// Where `Constructor` is the type constructor represented by `ConstructorTag` |
A string identifying the build system action being performed.
The locations of any sparse SDKs that should be layered on top of the one specified by Base SDK (SDKROOT). If more than one SDK is listed, the first one has highest precedence. Every SDK specified in this setting should be a "sparse" SDK, for example, not an SDK for an entire macOS release.
| const I = x => x; | |
| const K = x => y => x; | |
| const A = f => x => f(x); | |
| const T = x => f => f(x); | |
| const W = f => x => f(x)(x); | |
| const C = f => y => x => f(x)(y); | |
| const B = f => g => x => f(g(x)); | |
| const S = f => g => x => f(x)(g(x)); | |
| const P = f => g => x => y => f(g(x))(g(y)); | |
| const Y = f => (g => g(g))(g => f(x => g(g)(x))); |
| {-# LANGUAGE DeriveFunctor #-} | |
| module Main where | |
| type Algebra f a = f a -> a | |
| type Coalgebra f a = a -> f a | |
| newtype Fix f = In { out :: f (Fix f) } |
Monads and delimited control are very closely related, so it isn’t too hard to understand them in terms of one another. From a monadic point of view, the big idea is that if you have the computation m >>= f, then f is m’s continuation. It’s the function that is called with m’s result to continue execution after m returns.
If you have a long chain of binds, the continuation is just the composition of all of them. So, for example, if you have
m >>= f >>= g >>= hthen the continuation of m is f >=> g >=> h. Likewise, the continuation of m >>= f is g >=> h.
The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).
My take-aways are:
You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse