The Remote Monad Design Pattern
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Functional Javascript
www.it-ebooks.info www.it-ebooks.info Functional JavaScript Michael Fogus www.it-ebooks.info Functional JavaScript by Michael Fogus Copyright © 2013 Michael Fogus. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editor: Mary Treseler Indexer: Judith McConville Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Jasmine Kwityn Interior Designer: David Futato Proofreader: Jilly Gagnon Illustrator: Robert Romano May 2013: First Edition Revision History for the First Edition: 2013-05-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449360726 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Functional JavaScript, the image of an eider duck, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. -
What I Wish I Knew When Learning Haskell
What I Wish I Knew When Learning Haskell Stephen Diehl 2 Version This is the fifth major draft of this document since 2009. All versions of this text are freely available onmywebsite: 1. HTML Version http://dev.stephendiehl.com/hask/index.html 2. PDF Version http://dev.stephendiehl.com/hask/tutorial.pdf 3. EPUB Version http://dev.stephendiehl.com/hask/tutorial.epub 4. Kindle Version http://dev.stephendiehl.com/hask/tutorial.mobi Pull requests are always accepted for fixes and additional content. The only way this document will stayupto date and accurate through the kindness of readers like you and community patches and pull requests on Github. https://github.com/sdiehl/wiwinwlh Publish Date: March 3, 2020 Git Commit: 77482103ff953a8f189a050c4271919846a56612 Author This text is authored by Stephen Diehl. 1. Web: www.stephendiehl.com 2. Twitter: https://twitter.com/smdiehl 3. Github: https://github.com/sdiehl Special thanks to Erik Aker for copyediting assistance. Copyright © 20092020 Stephen Diehl This code included in the text is dedicated to the public domain. You can copy, modify, distribute and perform thecode, even for commercial purposes, all without asking permission. You may distribute this text in its full form freely, but may not reauthor or sublicense this work. Any reproductions of major portions of the text must include attribution. The software is provided ”as is”, without warranty of any kind, express or implied, including But not limitedtothe warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authorsor copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, Arising from, out of or in connection with the software or the use or other dealings in the software. -
Applicative Programming with Effects
Under consideration for publication in J. Functional Programming 1 FUNCTIONALPEARL Applicative programming with effects CONOR MCBRIDE University of Nottingham ROSS PATERSON City University, London Abstract In this paper, we introduce Applicative functors—an abstract characterisation of an ap- plicative style of effectful programming, weaker than Monads and hence more widespread. Indeed, it is the ubiquity of this programming pattern that drew us to the abstraction. We retrace our steps in this paper, introducing the applicative pattern by diverse exam- ples, then abstracting it to define the Applicative type class and introducing a bracket notation which interprets the normal application syntax in the idiom of an Applicative functor. Further, we develop the properties of applicative functors and the generic opera- tions they support. We close by identifying the categorical structure of applicative functors and examining their relationship both with Monads and with Arrows. 1 Introduction This is the story of a pattern that popped up time and again in our daily work, programming in Haskell (Peyton Jones, 2003), until the temptation to abstract it became irresistable. Let us illustrate with some examples. Sequencing commands One often wants to execute a sequence of commands and collect the sequence of their responses, and indeed there is such a function in the Haskell Prelude (here specialised to IO): sequence :: [IO a ] → IO [a ] sequence [ ] = return [] sequence (c : cs) = do x ← c xs ← sequence cs return (x : xs) In the (c : cs) case, we collect the values of some effectful computations, which we then use as the arguments to a pure function (:). We could avoid the need for names to wire these values through to their point of usage if we had a kind of ‘effectful application’. -
Learn You a Haskell for Great Good! © 2011 by Miran Lipovača 3 SYNTAX in FUNCTIONS 35 Pattern Matching
C ONTENTSINDETAIL INTRODUCTION xv So, What’s Haskell? .............................................................. xv What You Need to Dive In ........................................................ xvii Acknowledgments ................................................................ xviii 1 STARTING OUT 1 Calling Functions ................................................................. 3 Baby’s First Functions ............................................................. 5 An Intro to Lists ................................................................... 7 Concatenation ........................................................... 8 Accessing List Elements ................................................... 9 Lists Inside Lists .......................................................... 9 Comparing Lists ......................................................... 9 More List Operations ..................................................... 10 Texas Ranges .................................................................... 13 I’m a List Comprehension.......................................................... 15 Tuples ........................................................................... 18 Using Tuples............................................................. 19 Using Pairs .............................................................. 20 Finding the Right Triangle ................................................. 21 2 BELIEVE THE TYPE 23 Explicit Type Declaration .......................................................... 24 -
There Is No Fork: an Abstraction for Efficient, Concurrent, and Concise Data Access
There is no Fork: an Abstraction for Efficient, Concurrent, and Concise Data Access Simon Marlow Louis Brandy Jonathan Coens Jon Purdy Facebook Facebook Facebook Facebook [email protected] [email protected] [email protected] [email protected] Abstract concise business logic, uncluttered by performance-related details. We describe a new programming idiom for concurrency, based on In particular the programmer should not need to be concerned Applicative Functors, where concurrency is implicit in the Applica- with accessing external data efficiently. However, one particular tive <*> operator. The result is that concurrent programs can be problem often arises that creates a tension between conciseness and written in a natural applicative style, and they retain a high degree efficiency in this setting: accessing multiple remote data sources of clarity and modularity while executing with maximal concur- efficiently requires concurrency, and that normally requires the rency. This idiom is particularly useful for programming against programmer to intervene and program the concurrency explicitly. external data sources, where the application code is written without When the business logic is only concerned with reading data the use of explicit concurrency constructs, while the implementa- from external sources and not writing, the programmer doesn’t tion is able to batch together multiple requests for data from the care about the order in which data accesses happen, since there same source, and fetch data from multiple sources concurrently. are no side-effects that could make the result different when the Our abstraction uses a cache to ensure that multiple requests for order changes. So in this case the programmer would be entirely the same data return the same result, which frees the programmer happy with not having to specify either ordering or concurrency, from having to arrange to fetch data only once, which in turn leads and letting the system perform data access in the most efficient way to greater modularity. -
An Introduction to Applicative Functors
An Introduction to Applicative Functors Bocheng Zhou What Is an Applicative Functor? ● An Applicative functor is a Monoid in the category of endofunctors, what's the problem? ● WAT?! Functions in Haskell ● Functions in Haskell are first-order citizens ● Functions in Haskell are curried by default ○ f :: a -> b -> c is the curried form of g :: (a, b) -> c ○ f = curry g, g = uncurry f ● One type declaration, multiple interpretations ○ f :: a->b->c ○ f :: a->(b->c) ○ f :: (a->b)->c ○ Use parentheses when necessary: ■ >>= :: Monad m => m a -> (a -> m b) -> m b Functors ● A functor is a type of mapping between categories, which is applied in category theory. ● What the heck is category theory? Category Theory 101 ● A category is, in essence, a simple collection. It has three components: ○ A collection of objects ○ A collection of morphisms ○ A notion of composition of these morphisms ● Objects: X, Y, Z ● Morphisms: f :: X->Y, g :: Y->Z ● Composition: g . f :: X->Z Category Theory 101 ● Category laws: Functors Revisited ● Recall that a functor is a type of mapping between categories. ● Given categories C and D, a functor F :: C -> D ○ Maps any object A in C to F(A) in D ○ Maps morphisms f :: A -> B in C to F(f) :: F(A) -> F(B) in D Functors in Haskell class Functor f where fmap :: (a -> b) -> f a -> f b ● Recall that a functor maps morphisms f :: A -> B in C to F(f) :: F(A) -> F(B) in D ● morphisms ~ functions ● C ~ category of primitive data types like Integer, Char, etc. -
It's All About Morphisms
It’s All About Morphisms Uberto Barbini @ramtop https://medium.com/@ramtop About me OOP programmer Agile TDD Functional PRogramming Finance Kotlin Industry Blog: https://medium.com/@ ramtop Twitter: @ramtop #morphisms#VoxxedVienna @ramtop Map of this presentation Monoid Category Monad Functor Natural Transformation Yoneda Applicative Morphisms all the way down... #morphisms#VoxxedVienna @ramtop I don’t care about Monads, why should I? Neither do I what I care about is y el is to define system behaviour ec Pr #morphisms#VoxxedVienna @ramtop This presentation will be a success if most of you will not fall asleep #morphisms#VoxxedVienna @ramtop This presentation will be a success if You will consider that Functional Programming is about transformations and preserving properties. Not (only) lambdas and flatmap #morphisms#VoxxedVienna @ramtop What is this Category thingy? Invented in 1940s “with the goal of understanding the processes that preserve mathematical structure.” “Category Theory is about relation between things” “General abstract nonsense” #morphisms#VoxxedVienna @ramtop Once upon a time there was a Category of Stuffed Toys and a Category of Tigers... #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 1) A collection of Objects #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 2) A collection of Arrows #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 3) Each Arrow works on 2 Objects #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 4) Arrows can be combined #morphisms#VoxxedVienna -
Combinatorial Species and Labelled Structures Brent Yorgey University of Pennsylvania, [email protected]
University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations 1-1-2014 Combinatorial Species and Labelled Structures Brent Yorgey University of Pennsylvania, [email protected] Follow this and additional works at: http://repository.upenn.edu/edissertations Part of the Computer Sciences Commons, and the Mathematics Commons Recommended Citation Yorgey, Brent, "Combinatorial Species and Labelled Structures" (2014). Publicly Accessible Penn Dissertations. 1512. http://repository.upenn.edu/edissertations/1512 This paper is posted at ScholarlyCommons. http://repository.upenn.edu/edissertations/1512 For more information, please contact [email protected]. Combinatorial Species and Labelled Structures Abstract The theory of combinatorial species was developed in the 1980s as part of the mathematical subfield of enumerative combinatorics, unifying and putting on a firmer theoretical basis a collection of techniques centered around generating functions. The theory of algebraic data types was developed, around the same time, in functional programming languages such as Hope and Miranda, and is still used today in languages such as Haskell, the ML family, and Scala. Despite their disparate origins, the two theories have striking similarities. In particular, both constitute algebraic frameworks in which to construct structures of interest. Though the similarity has not gone unnoticed, a link between combinatorial species and algebraic data types has never been systematically explored. This dissertation lays the theoretical groundwork for a precise—and, hopefully, useful—bridge bewteen the two theories. One of the key contributions is to port the theory of species from a classical, untyped set theory to a constructive type theory. This porting process is nontrivial, and involves fundamental issues related to equality and finiteness; the recently developed homotopy type theory is put to good use formalizing these issues in a satisfactory way. -
Uusi Hakemisto
214 6. Tunneling 215 ROCK EXCAVATION HANDBOOK 6.1. GENERAL SELECTING TUNNELING METHODS In modern tunnel and underground cavern excavation, it is possible to select from many dif- ferent methods. The following factors should be taken into consideration when selecting the method: - Tunnel dimensions - Tunnel geometry - Length of tunnel, total volume to be excavated - Geological and rock mechanical conditions - Ground water level and expected water inflow - Vibration restrictions FIGURE 6.1.-2. Range of methods compared to uniaxal compressive strength. - Allowed ground settlements The methods can be divided into drill & blast, and mechanical excavation. Mechanical meth- ods can be split further to partial face (e.g. roadheaders, hammers, excavators) or full face (TBM, shield, pipe jacking, micro tunneling). FIGURE 6.1.-1. Tunneling methods in different rock/soil conditions. The drill & blast method is still the most typical method for medium to hard rock conditions. It can be applied to a wide range of rock conditions. Some of its features include versatile equipment, fast start-up and relatively low capital cost tied to the equipment. On the other hand, the cyclic nature of the drill & blast method requires good work site organization. FIGURE 6.1.-3. Drill and blast cycle. Blast vibrations and noise also restrict the use of drill & blast in urban areas. 216 6. Tunneling 217 ROCK EXCAVATION HANDBOOK Hard-rock TBMs can be used in relatively soft to hard rock conditions, and best when rock DRIFTING AND TUNNELING fracturing & weakness zones are predictable. The TBM is most economical method for longer tunnel lengths, in which its high investment cost and timely build-up can be utilized by the Many mines and excavation sites still plan their drilling patterns manually, but advanced high advance rate of excavation. -
View on 5G Architecture
5G PPP Architecture Working Group View on 5G Architecture Version 3.0, June 2019 Date: 2019-06-19 Version: 3.0 Dissemination level: Public Consultation Abstract The 5G Architecture Working Group as part of the 5G PPP Initiative is looking at capturing novel trends and key technological enablers for the realization of the 5G architecture. It also targets at presenting in a harmonized way the architectural concepts developed in various projects and initiatives (not limited to 5G PPP projects only) so as to provide a consolidated view on the technical directions for the architecture design in the 5G era. The first version of the white paper was released in July 2016, which captured novel trends and key technological enablers for the realization of the 5G architecture vision along with harmonized architectural concepts from 5G PPP Phase 1 projects and initiatives. Capitalizing on the architectural vision and framework set by the first version of the white paper, the Version 2.0 of the white paper was released in January 2018 and presented the latest findings and analyses of 5G PPP Phase I projects along with the concept evaluations. The work has continued with the 5G PPP Phase II and Phase III projects with special focus on understanding the requirements from vertical industries involved in the projects and then driving the required enhancements of the 5G Architecture able to meet their requirements. The results of the Working Group are now captured in this Version 3.0, which presents the consolidated European view on the architecture design. Dissemination level: Public Consultation Table of Contents 1 Introduction........................................................................................................................ -
Httpclient-Tutorial.Pdf
HttpClient Tutorial Oleg Kalnichevski Jonathan Moore Jilles van Gurp Preface .................................................................................................................................... iv 1. HttpClient scope .......................................................................................................... iv 2. What HttpClient is NOT .............................................................................................. iv 1. Fundamentals ....................................................................................................................... 1 1.1. Request execution ...................................................................................................... 1 1.1.1. HTTP request .................................................................................................. 1 1.1.2. HTTP response ............................................................................................... 2 1.1.3. Working with message headers ........................................................................ 2 1.1.4. HTTP entity .................................................................................................... 3 1.1.5. Ensuring release of low level resources ............................................................ 5 1.1.6. Consuming entity content ................................................................................ 6 1.1.7. Producing entity content .................................................................................. 6 1.1.8. Response -
Cofree Traversable Functors
IT 19 035 Examensarbete 15 hp September 2019 Cofree Traversable Functors Love Waern Institutionen för informationsteknologi Department of Information Technology Abstract Cofree Traversable Functors Love Waern Teknisk- naturvetenskaplig fakultet UTH-enheten Traversable functors see widespread use in purely functional programming as an approach to the iterator pattern. Unlike other commonly used functor families, free Besöksadress: constructions of traversable functors have not yet been described. Free constructions Ångströmlaboratoriet Lägerhyddsvägen 1 have previously found powerful applications in purely functional programming, as they Hus 4, Plan 0 embody the concept of providing the minimal amount of structure needed to create members of a complex family out of members of a simpler, underlying family. This Postadress: thesis introduces Cofree Traversable Functors, together with a provably valid Box 536 751 21 Uppsala implementation, thereby developing a family of free constructions for traversable functors. As free constructions, cofree traversable functors may be used in order to Telefon: create novel traversable functors from regular functors. Cofree traversable functors 018 – 471 30 03 may also be leveraged in order to manipulate traversable functors generically. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Justin Pearson Ämnesgranskare: Tjark Weber Examinator: Johannes Borgström IT 19 035 Tryckt av: Reprocentralen ITC Contents 1 Introduction7 2 Background9 2.1 Parametric Polymorphism and Kinds..............9 2.2 Type Classes........................... 11 2.3 Functors and Natural Transformations............. 12 2.4 Applicative Functors....................... 15 2.5 Traversable Functors....................... 17 2.6 Traversable Morphisms...................... 22 2.7 Free Constructions........................ 25 3 Method 27 4 Category-Theoretical Definition 28 4.1 Applicative Functors and Applicative Morphisms......