A Review Article on Cryptography Using Functional Programming:Haskell
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Akka Java Documentation Release 2.2.5
Akka Java Documentation Release 2.2.5 Typesafe Inc February 19, 2015 CONTENTS 1 Introduction 1 1.1 What is Akka?............................................1 1.2 Why Akka?..............................................3 1.3 Getting Started............................................3 1.4 The Obligatory Hello World.....................................7 1.5 Use-case and Deployment Scenarios.................................8 1.6 Examples of use-cases for Akka...................................9 2 General 10 2.1 Terminology, Concepts........................................ 10 2.2 Actor Systems............................................ 12 2.3 What is an Actor?.......................................... 14 2.4 Supervision and Monitoring..................................... 16 2.5 Actor References, Paths and Addresses............................... 19 2.6 Location Transparency........................................ 25 2.7 Akka and the Java Memory Model.................................. 26 2.8 Message Delivery Guarantees.................................... 28 2.9 Configuration............................................. 33 3 Actors 65 3.1 Actors................................................ 65 3.2 Typed Actors............................................. 84 3.3 Fault Tolerance............................................ 88 3.4 Dispatchers.............................................. 103 3.5 Mailboxes.............................................. 106 3.6 Routing................................................ 111 3.7 Building Finite State Machine -
GHC Reading Guide
GHC Reading Guide - Exploring entrances and mental models to the source code - Takenobu T. Rev. 0.01.1 WIP NOTE: - This is not an official document by the ghc development team. - Please refer to the official documents in detail. - Don't forget “semantics”. It's very important. - This is written for ghc 9.0. Contents Introduction 1. Compiler - Compilation pipeline - Each pipeline stages - Intermediate language syntax - Call graph 2. Runtime system 3. Core libraries Appendix References Introduction Introduction Official resources are here GHC source repository : The GHC Commentary (for developers) : https://gitlab.haskell.org/ghc/ghc https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary GHC Documentation (for users) : * master HEAD https://ghc.gitlab.haskell.org/ghc/doc/ * latest major release https://downloads.haskell.org/~ghc/latest/docs/html/ * version specified https://downloads.haskell.org/~ghc/9.0.1/docs/html/ The User's Guide Core Libraries GHC API Introduction The GHC = Compiler + Runtime System (RTS) + Core Libraries Haskell source (.hs) GHC compiler RuntimeSystem Core Libraries object (.o) (libHsRts.o) (GHC.Base, ...) Linker Executable binary including the RTS (* static link case) Introduction Each division is located in the GHC source tree GHC source repository : https://gitlab.haskell.org/ghc/ghc compiler/ ... compiler sources rts/ ... runtime system sources libraries/ ... core library sources ghc/ ... compiler main includes/ ... include files testsuite/ ... test suites nofib/ ... performance tests mk/ ... build system hadrian/ ... hadrian build system docs/ ... documents : : 1. Compiler 1. Compiler Compilation pipeline 1. compiler The GHC compiler Haskell language GHC compiler Assembly language (native or llvm) 1. compiler GHC compiler comprises pipeline stages GHC compiler Haskell language Parser Renamer Type checker Desugarer Core to Core Core to STG STG to Cmm Assembly language Cmm to Asm (native or llvm) 1. -
Parsing with First-Class Derivatives
Parsing with First-Class Derivatives Jonathan Immanuel Brachthauser¨ Tillmann Rendel Klaus Ostermann rtifact A Comple * t * te n * A * te is W E s A e n C l l L o D C S University of Tubingen,¨ Germany o * * c P u e m s E u O e e n v R t e O o d t a y * s E a * fbrachthaeuser, rendel, [email protected] l u d a e t Abstract often reducing the modularity of their parser because these ad- Brzozowski derivatives, well known in the context of reg- hoc additions are cross-cutting with respect to the otherwise ular expressions, have recently been rediscovered to give a context-free syntactic structure of the language. simplified explanation to parsers of context-free languages. Parser combinators [10, 10, 15, 21, 22] are a parsing We add derivatives as a novel first-class feature to a standard approach that is well-suited for such ad-hoc additions. With parser combinator language. First-class derivatives enable an parser combinators, a parser is described as a first-class inversion of the control flow, allowing to implement modular entity in some host language, and parsers for smaller subsets parsers for languages that previously required separate pre- of a language are combined into parsers of larger subsets processing steps or cross-cutting modifications of the parsers. using built-in or user-defined combinators such as sequence, We show that our framework offers new opportunities for alternative, or iteration. The fact that parsers are first-class reuse and supports a modular definition of interesting use entities at runtime allows an elegant way of structuring cases of layout-sensitive parsing. -
Warp: a Haskell Web Server
The Functional Web Warp: A Haskell Web Server Michael Snoyman • Suite Solutions oughly two years ago, I began work on about this runtime is its lightweight threads. As the Yesod Web framework. I originally a result of this feature, Warp simply spawns a R intended FastCGI for my deployment strat- new thread for each incoming connection, bliss- egy, but I also created a simple HTTP server for fully unaware of the gymnastics the runtime is local testing, creatively named SimpleServer. performing under the surface. Because Yesod targets the Web Application Part of this abstraction involves converting Interface (WAI), a standard interface between synchronous Haskell I/O calls into asynchro- Haskell Web servers and Web applications, it nous system calls. Once again, Warp reaps the was easy to switch back ends for testing and benefits by calling simple functions like recv production. and send, while GHC does the hard work. It didn’t take long before I started getting Up through GHC 6.12, this runtime sys- feature requests for SimpleServer: slowly but tem was based on the select system call. This surely, features such as chunked transfer encod- worked well enough for many tasks but didn’t ing and sendfile-based file serving made their scale for Web servers. One big feature of the way in. The tipping point was when Matt Brown GHC 7 release was a new event manager, written of Soft Mechanics made some minor tweaks by Google’s Johan Tibell and Serpentine’s Bryan to SimpleServer and found that it was already O’Sullivan. This new runtime uses different sys- the fastest Web server in Haskell (see Figure 1). -
Interleaving Data and Effects"
Archived version from NCDOCKS Institutional Repository http://libres.uncg.edu/ir/asu/ Interleaving data and effects By: Robert Atkey and Patricia Johann Abstract: The study of programming with and reasoning about inductive datatypes such as lists and trees has benefited from the simple categorical principle of initial algebras. In initial algebra semantics, each inductive datatype is represented by an initial f-algebra for an appropriate functor f. The initial algebra principle then supports the straightforward derivation of definitional principles and proof principles for these datatypes. This technique has been expanded to a whole methodology of structured functional programming, often called origami programming.In this article we show how to extend initial algebra semantics from pure inductive datatypes to inductive datatypes interleaved with computational effects. Inductive datatypes interleaved with effects arise naturally in many computational settings. For example, incrementally reading characters from a file generates a list of characters interleaved with input/output actions, and lazily constructed infinite values can be represented by pure data interleaved with the possibility of non-terminating computation. Straightforward application of initial algebra techniques to effectful datatypes leads either to unsound conclusions if we ignore the possibility of effects, or to unnecessarily complicated reasoning because the pure and effectful concerns must be considered simultaneously. We show how pure and effectful concerns can be separated using the abstraction of initial f-and-m-algebras, where the functor f describes the pure part of a datatype and the monad m describes the interleaved effects. Because initial f-and-m-algebras are the analogue for the effectful setting of initial f- algebras, they support the extension of the standard definitional and proof principles to the effectful setting. -
Haskell-Like S-Expression-Based Language Designed for an IDE
Department of Computing Imperial College London MEng Individual Project Haskell-Like S-Expression-Based Language Designed for an IDE Author: Supervisor: Michal Srb Prof. Susan Eisenbach June 2015 Abstract The state of the programmers’ toolbox is abysmal. Although substantial effort is put into the development of powerful integrated development environments (IDEs), their features often lack capabilities desired by programmers and target primarily classical object oriented languages. This report documents the results of designing a modern programming language with its IDE in mind. We introduce a new statically typed functional language with strong metaprogramming capabilities, targeting JavaScript, the most popular runtime of today; and its accompanying browser-based IDE. We demonstrate the advantages resulting from designing both the language and its IDE at the same time and evaluate the resulting environment by employing it to solve a variety of nontrivial programming tasks. Our results demonstrate that programmers can greatly benefit from the combined application of modern approaches to programming tools. I would like to express my sincere gratitude to Susan, Sophia and Tristan for their invaluable feedback on this project, my family, my parents Michal and Jana and my grandmothers Hana and Jaroslava for supporting me throughout my studies, and to all my friends, especially to Harry whom I met at the interview day and seem to not be able to get rid of ever since. ii Contents Abstract i Contents iii 1 Introduction 1 1.1 Objectives ........................................ 2 1.2 Challenges ........................................ 3 1.3 Contributions ...................................... 4 2 State of the Art 6 2.1 Languages ........................................ 6 2.1.1 Haskell .................................... -
On the Duality of Streams How Can Linear Types Help to Solve the Lazy IO Problem?
Draft: do not distribute On the Duality of Streams How Can Linear Types Help to Solve the Lazy IO Problem? Jean-Philippe Bernardy Josef Svenningsson Chalmers University of Technology and University of Gothenburg bernardy,josefs at chalmers.se Abstract sired behavior does not always happen. Indeed, a necessary con- We present a novel stream-programming library for Haskell. As dition is that the production pattern of f matches the consumption other coroutine-based stream libraries, our library allows syn- pattern of g; otherwise buffering occurs. In practice, this means that chronous execution, which implies that effects are run in lockstep a seemingly innocuous change in either of the function definitions and no buffering occurs. may drastically change the memory behavior of the composition, A novelty of our implementation is that it allows to locally in- without warning. If one cares about memory behavior, this means troduce buffering or re-scheduling of effects. The buffering require- that the compositionality principle touted by Hughes breaks down. ments (or re-scheduling opportunities) are indicated by the type- Second, lazy evaluation does not extend nicely to effectful pro- system. cessing. That is, if (say) an input list is produced by reading a file lazily, one is exposed to losing referential transparency (as ? has Our library is based on a number of design principles, adapted 1 from the theory of Girard’s Linear Logic. These principles are shown). For example, one may rightfully expect that both follow- applicable to the design of any Haskell structure where resource ing programs have the same behavior: management (memory, IO, ...) is critical. -
A Formal Methodology for Deriving Purely Functional Programs from Z Specifications Via the Intermediate Specification Language Funz
Louisiana State University LSU Digital Commons LSU Historical Dissertations and Theses Graduate School 1995 A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ. Linda Bostwick Sherrell Louisiana State University and Agricultural & Mechanical College Follow this and additional works at: https://digitalcommons.lsu.edu/gradschool_disstheses Recommended Citation Sherrell, Linda Bostwick, "A Formal Methodology for Deriving Purely Functional Programs From Z Specifications via the Intermediate Specification Language FunZ." (1995). LSU Historical Dissertations and Theses. 5981. https://digitalcommons.lsu.edu/gradschool_disstheses/5981 This Dissertation is brought to you for free and open access by the Graduate School at LSU Digital Commons. It has been accepted for inclusion in LSU Historical Dissertations and Theses by an authorized administrator of LSU Digital Commons. For more information, please contact [email protected]. INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. H ie quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandardm argins, and improper alignment can adversely affect reproduction. In the unlikely, event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. -
The Logic of Demand in Haskell
Under consideration for publication in J. Functional Programming 1 The Logic of Demand in Haskell WILLIAM L. HARRISON Department of Computer Science University of Missouri Columbia, Missouri RICHARD B. KIEBURTZ Pacific Software Research Center OGI School of Science & Engineering Oregon Health & Science University Abstract Haskell is a functional programming language whose evaluation is lazy by default. However, Haskell also provides pattern matching facilities which add a modicum of eagerness to its otherwise lazy default evaluation. This mixed or “non-strict” semantics can be quite difficult to reason with. This paper introduces a programming logic, P-logic, which neatly formalizes the mixed evaluation in Haskell pattern-matching as a logic, thereby simplifying the task of specifying and verifying Haskell programs. In P-logic, aspects of demand are reflected or represented within both the predicate language and its model theory, allowing for expressive and comprehensible program verification. 1 Introduction Although Haskell is known as a lazy functional language because of its default eval- uation strategy, it contains a number of language constructs that force exceptions to that strategy. Among these features are pattern-matching, data type strictness annotations and the seq primitive. The semantics of pattern-matching are further enriched by irrefutable pattern annotations, which may be embedded within pat- terns. The interaction between Haskell’s default lazy evaluation and its pattern- matching is surprisingly complicated. Although it offers the programmer a facility for fine control of demand (Harrison et al., 2002), it is perhaps the aspect of the Haskell language least well understood by its community of users. In this paper, we characterize the control of demand first in a denotational semantics and then in a verification logic called “P-logic”. -
A Companion Booklet to "Functional Programming in Scala"
A companion booklet to ”Functional Programming in Scala” Chapter notes, errata, hints, and answers to exercises Rúnar Óli Bjarnason This book is for sale at http://leanpub.com/fpinscalacompanion This version was published on 2015-03-05 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. ©2015 Manning Publications Co., Rúnar Óli Bjarnason, and other contributors Contents About this booklet ......................................... 2 Why make this? ......................................... 2 License .............................................. 2 Errata ................................................ 3 Chapter notes ........................................... 6 Getting answers to your questions ............................... 6 Notes on chapter 1: What is functional programming? .................... 6 Notes on chapter 2: Getting started ............................... 7 Notes on chapter 3: Functional data structures ........................ 9 Notes on chapter 4: Handling errors without exceptions ................... 12 Notes on chapter 5: Strictness and laziness .......................... 14 Notes on chapter 6: Purely functional state .......................... 16 Notes on chapter 7: Purely functional parallelism ....................... 20 Notes on chapter 8: Property-based testing ......................... -
Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers
Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Jeremy Singer and Blair Archibald School of Computing Science University of Glasgow UK [email protected] [email protected] What kinds of mistakes are made by novice Haskell developers, as they learn about functional pro- gramming? Is it possible to analyze these errors in order to improve the pedagogy of Haskell? In 2016, we delivered a massive open online course which featured an interactive code evaluation en- vironment. We captured and analyzed 161K interactions from learners. We report typical novice developer behavior; for instance, the mean time spent on an interactive tutorial is around eight min- utes. Although our environment was restricted, we gain some understanding of Haskell novice er- rors. Parenthesis mismatches, lexical scoping errors and do block misunderstandings are common. Finally, we make recommendations about how such beginner code evaluation environments might be enhanced. 1 Introduction The Haskell programming language [14] has acquired a reputation for being difficult to learn. In his presentation on the origins of Haskell [23] Peyton Jones notes that, according to various programming language popularity metrics, Haskell is much more frequently discussed than it is used for software implementation. The xkcd comic series features a sarcastic strip on Haskell’s side-effect free property [21]. Haskell code is free from side-effects ‘because no-one will ever run it.’ In 2016, we ran the first instance of a massive open online course (MOOC) at Glasgow, providing an introduction to functional programming in Haskell. We received many items of learner feedback that indicated difficulty in learning Haskell. -
A Brief Overview of Functional Programming Languages
electronic Journal of Computer Science and Information Technology (eJCSIT), Vol. 6, No. 1, 2016 A Brief Overview of Functional Programming Languages Jagatheesan Kunasaikaran1, Azlan Iqbal2 1ZALORA Malaysia, Jalan Dua, Chan Sow Lin, Kuala Lumpur, Malaysia e-mail: [email protected] 2College of Computer Science and Information Technology, Universiti Tenaga Nasional, Putrajaya Campus, Selangor, Malaysia e-mail: [email protected] Abstract – Functional programming is an important Common programming paradigms are procedural, object- programming paradigm. It is based on a branch of oriented and functional. Figure 1 illustrates conceptually mathematics known as lambda calculus. In this article, we the differences between the common programming provide a brief overview, aimed at those new to the field, and language paradigms [1]. Procedural and object-oriented explain the progress of functional programming since its paradigms mutate or alter the data along program inception. A selection of functional languages are provided as examples. We also suggest some improvements and speculate execution. On the other hand, in pure functional style, the on the potential future directions of this paradigm. data does not exist by itself or independently. A composition of function calls with a set of arguments Keywords – functional, programming languages, LISP, Python; generates the final result that is expected. Each function is Javascript,Java, Elm, Haskell ‘atomic’ as it only executes operations defined in it to the input data and returns the result of the computation to the ‘callee’. I. INTRODUCTION II. FUNCTIONAL LANGUAGES Programming languages can be classified into the style of programming each language supports. There are multiple Functional programming is based on mathematical logic.