DOCSLIB.ORG

Solving the Funarg Problem with Static Types IFL ’21, September 01–03, 2021, Online

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Solving the Funarg Problem with Static Types IFL ’21, September 01–03, 2021, Online Solving the Funarg Problem with Static Types Caleb Helbling Fırat Aksoy [email protected] fi[email protected] Purdue University Istanbul University West Lafayette, Indiana, USA Istanbul, Turkey ABSTRACT downwards. The upwards funarg problem refers to the manage- The difficulty associated with storing closures in a stack-based en- ment of the stack when a function returns another function (that vironment is known as the funarg problem. The funarg problem may potentially have a non-empty closure), whereas the down- was first identified with the development of Lisp in the 1970s and wards funarg problem refers to the management of the stack when hasn’t received much attention since then. The modern solution a function is passed to another function (that may also have a non- taken by most languages is to allocate closures on the heap, or to empty closure). apply static analysis to determine when closures can be stack allo- Solving the upwards funarg problem is considered to be much cated. This is not a problem for most computing systems as there is more difficult than the downwards funarg problem. The downwards an abundance of memory. However, embedded systems often have funarg problem is easily solved by copying the closure’s lexical limited memory resources where heap allocation may cause mem- scope (captured variables) to the top of the program’s stack. For ory fragmentation. We present a simple extension to the prenex the upwards funarg problem, an issue arises with deallocation. A fragment of System F that allows closures to be stack-allocated. returning function may capture local variables, making the size of We demonstrate a concrete implementation of this system in the the closure dynamic. Due to this behavior, the closure itself can- Juniper functional reactive programming language, which is de- not be copied down the stack without causing stack corruption. signed to run on extremely resource limited Arduino devices. We We must keep in mind that, as soon as the function returns, any also discuss other solutions present in other programming languages local variables will be lost when they are popped off the stack. that solve the funarg problem but haven’t been formally discussed In 1968, Weizenbaum [12] made an analysis of function closures in the literature. using lambda calculus, and showed that function closures in lambda calculus cannot have a stack based data structure and must in fact CCS CONCEPTS consist of a tree. Moses [9] further analyzed the problem for the Algol programming language. Early attempts to solve the funarg • Software and its engineering → Procedures, functions and problem [10] appear to be hampered by a number of factors, includ- subroutines; Functional languages. ing dynamic scoping, lack of static types and mutable variables. KEYWORDS Despite the titles of these early papers, we contend that the fu- narg problem (in particular, the upwards funarg problem) has not funarg, closure, stack, heap, memory, functional, embedded been adequately solved. In our approach, we solve the upwards fu- ACM Reference Format: narg problem by statically determining a closure’s size at compile Caleb Helbling and Fırat Aksoy. 2021. Solving the Funarg Problem with time. This allows the closure from the upwards funarg problem to Static Types. In IFL ’21: ACM Symposium on Implementation and Application be copied into the calling function, as if it were any other stati- of Functional Languages, September 01–03, 2021, Online. ACM, New York, cally sized piece of data. Since the type of a closure’s lexical scope NY, USA, 5 pages. https://doi.org/10.1145/1122445.1122456 can be viewed as a structural record type, we can make our lan- guage polymorphic over closures and their lexical scopes. This al- 1 INTRODUCTION lows higher order functions such as map (downwards funarg prob- lem) and compose (upwards and downwards funarg problem) to arXiv:2108.07389v2 [cs.PL] 22 Aug 2021 The funarg problem refers to the difficulty associated with compi- lation of first-class functions in programming languages for stack- be written very concisely and naturally. based environments. The problem arises in the bodies of nested Analyzing closures from a type theoretic perspective is not a functions where the nested function refers to identifiers defined new exercise [1, 6–8]. These papers prefer to treat closures as ex- in the parent function’s lexical scope which are not available in plicit environments, whose type is determined by an existential. it’s own lexical scope. The standard solution is to allocate closures This is not helpful to solving the funarg problem, since existen- on the heap. There are two variants of this problem: upwards and tials are typically treated as boxed values and must be allocated on the heap. Therefore our contribution is unique in the sense that Permission to make digital or hard copies of all or part of this work for personal or we seek to solve the funarg problem rather than analyzing closures classroom use is granted without fee provided that copies are not made or distributed from a purely type theoretic environmental perspective. for profit or commercial advantage and that copies bear this notice and the full cita- tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- publish, to post on servers or to redistribute to lists, requires prior specific permission 1.1 Contributions and/or a fee. Request permissions from [email protected]. We describe the following contributions: IFL ’21, September 01–03, 2021, Online © 2021 Association for Computing Machinery. ACM ISBN 978-1-4503-XXXX-X/18/06...$15.00 • We demonstrate how the prenex fragment of System F can https://doi.org/10.1145/1122445.1122456 be extended to enable stack allocated closures. IFL ’21, September 01–03, 2021, Online Helbling and Aksoy environment along with the lambda’s argument for further evalu- Expressions ation. Figure 1 presents the big-step semantics for our language. 4 := G | _G : .4 | 41 42 | ΛU.4 | 4 = Δ( ) Type Schemes E G Δ [EVAL-VAR] f := |∀0.f ⊢ G ⇓ E Types , , := U | − → | X Δ ⊢ _G : .4 ⇓ (_G.4)[{~ 7→ Δ(~) | ~ ∈ fv(_G : .4)}] [EVAL-ABS] Lexical Scope Types X := {G : , ..., G= : = } 0 0 ′ ′ Δ1 ⊢ 41 ⇓ (_G.43)[Δ2] Δ1 ⊢ 42 ⇓ E Δ2, G 7→ E ⊢ 43 ⇓ E Values Δ1 ⊢ 41 42 ⇓ E E := (_G.4)[Δ] | Λ.4 [EVAL-APP] Contexts Γ ::= ∅ | Γ,U | Γ, G : [EVAL-TABS] Δ ⊢ ΛU.4 ⇓ Λ.4 Environments Δ := {G 7→ E , ..., G= 7→ E= } Δ ⊢ 41 ⇓ Λ.42 Δ ⊢ 42 ⇓ E 0 0 [EVAL-TAPP] Δ ⊢ 41 ⇓ E Table 1: Grammar Figure 1: Big step semantics • We discuss a concrete implementation of this approach in 2.2 Typing the Juniper programming language. Figure 2 presents the typing rules for our language. There are sev- • We analyze the limitations of the extension and identify the eral changes made to the type rules for the prenex fragment of Sys- connection between types and closures. tem F. Of primary interest is the T-ABS rule which also constructs • We make an analysis of other approaches found in exist- the type of the lexical scope. The construction of the lexical scope ing programming languages, but haven’t been discussed for- itself is performed by T-DELTA, which finds all free variables within mally in the literature. the lambda, looks up their type in Γ and returns the corresponding lexical scope type. The rule T-TABS is also changed to restrict type 2 EXTENDING SYSTEM F abstractions to contain no free variables themselves which simpli- In this section, we restrict and extend System F to enable stack allo- fies the type system and assists in compilation to a stack based cated closures. We restrict System F to it’s prenex fragment which environment. separates regular System F types into type schemes and types. This is a necessary restriction to prevent the emergence of existential 2.3 Examples types in the type system which prevents determining the sizes of In this section, we will look at two examples that demonstrate that types at compile-time. The primary addition is that of the closure our solution for the funarg problem works for accurately typing types, which are defined as function types with their lexical scopes two of the most commonly used functions in functional program- attached to them. The lexical scopes X are either type variables ming: map and compose. For the map example, we will assume or records of captured variables and their respective types. These that the type system is enriched with a list type constructor. The lexical scope types are are considered equivalent if both the field type of these functions are considerably more noisy than the stan- names and the types of those fields are identical. These additions dard System F types. Fortunately, most of the noise can be elided make it possible for closures to be polymorphic and enable stack through type inference. allocation of the closure since the size of the closure is known stati- cally at compile-time. Table 1 defines the grammar of our language. <0? : ∀U.∀V.∀X.(U−X → V)−{} → U list−{5 : U−X → V}→ V list 2.1 Big-step semantics For the compose example we give the definition of compose as Stack allocation of closures require the lambda values and their lex- well as its type in our System F extension. ical scopes to be propagated and used in pairs. For this reason, we combine the lambda values with their environments into a single 2><?>B4 := ΛU.ΛV.ΛW.ΛX1 .ΛX2. value representation.
Load more

Recommended publications
  • Top-K Entity Resolution with Adaptive Locality-Sensitive Hashing
    Top-K Entity Resolution with Adaptive Locality-Sensitive Hashing Vasilis Verroios Hector Garcia-Molina Stanford University Stanford University [email protected] [email protected] ABSTRACT Given a set of records, entity resolution algorithms find all the records referring to each entity. In this paper, we study Entity 1 the problem of top-k entity resolution: finding all the records Entity 2 referring to the k largest (in terms of records) entities. Top-k Top-k Entity entity resolution is driven by many modern applications that Dataset Filtering Entities’ Records Resolution operate over just the few most popular entities in a dataset. We propose a novel approach, based on locality-sensitive hashing, that can very rapidly and accurately process mas- Entity k sive datasets. Our key insight is to adaptively decide how much processing each record requires to ascertain if it refers to a top-k entity or not: the less likely a record is to refer to Figure 1: Filtering stage in the overall workflow. a top-k entity, the less it is processed. The heavily reduced rest. As we will see, this fact makes it easier to find the top- amount of processing for the vast majority of records that k entities without computing all entities. We next illustrate do not refer to top-k entities, leads to significant speedups. two additional applications where one typically only needs Our experiments with images, web articles, and scientific top-k entities. Incidentally, two of the datasets we use for publications show a 2x to 25x speedup compared to the tra- our experiments are from these applications.
    [Show full text]
  • Dynamic Variables
    Dynamic Variables David R. Hanson and Todd A. Proebsting Microsoft Research [email protected] [email protected] November 2000 Technical Report MSR-TR-2000-109 Abstract Most programming languages use static scope rules for associating uses of identifiers with their declarations. Static scope helps catch errors at compile time, and it can be implemented efficiently. Some popular languages—Perl, Tcl, TeX, and Postscript—use dynamic scope, because dynamic scope works well for variables that “customize” the execution environment, for example. Programmers must simulate dynamic scope to implement this kind of usage in statically scoped languages. This paper describes the design and implementation of imperative language constructs for introducing and referencing dynamically scoped variables—dynamic variables for short. The design is a minimalist one, because dynamic variables are best used sparingly, much like exceptions. The facility does, however, cater to the typical uses for dynamic scope, and it provides a cleaner mechanism for so-called thread-local variables. A particularly simple implementation suffices for languages without exception handling. For languages with exception handling, a more efficient implementation builds on existing compiler infrastructure. Exception handling can be viewed as a control construct with dynamic scope. Likewise, dynamic variables are a data construct with dynamic scope. Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 http://www.research.microsoft.com/ Dynamic Variables Introduction Nearly all modern programming languages use static (or lexical) scope rules for determining variable bindings. Static scope can be implemented very efficiently and makes programs easier to understand. Dynamic scope is usu- ally associated with “older” languages; notable examples include Lisp, SNOBOL4, and APL.
    [Show full text]
  • On the Expressive Power of Programming Languages for Generative Design
    On the Expressive Power of Programming Languages for Generative Design The Case of Higher-Order Functions António Leitão1, Sara Proença2 1,2INESC-ID, Instituto Superior Técnico, Universidade de Lisboa 1,2{antonio.menezes.leitao|sara.proenca}@ist.utl.pt The expressive power of a language measures the breadth of ideas that can be described in that language and is strongly dependent on the constructs provided by the language. In the programming language area, one of the constructs that increases the expressive power is the concept of higher-order function (HOF). A HOF is a function that accepts functions as arguments and/or returns functions as results. HOF can drastically simplify the programming activity, reducing the development effort, and allowing for more adaptable programs. In this paper we explain the concept of HOFs and its use for Generative Design. We then compare the support for HOF in the most used programming languages in the GD field and we discuss the pedagogy of HOFs. Keywords: Generative Design, Higher-Order Functions, Programming Languages INTRODUCTION ming language is Turing-complete, meaning that Generative Design (GD) involves the use of algo- almost all programming languages have the same rithms that compute designs (McCormack 2004, Ter- computational power. In what regards their expres- dizis 2003). In order to take advantage of comput- sive power, however, they can be very different. A ers, these algorithms must be implemented in a pro- given programming language can be textual, visual, gramming language. There are two important con- or both but, in any case, it must be expressive enough cepts concerning programming languages: compu- to allow the description of a large range of algo- tational power, which measures the complexity of rithms.
    [Show full text]
  • Java: Exercises in Style
    Java: Exercises in Style Marco Faella June 1, 2018 i ii This work is licensed under the Creative Commons Attribution- NonCommercial 4.0 International License. To view a copy of this li- cense, visit http://creativecommons.org/licenses/by-nc/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Author: Marco Faella, [email protected] Preface to the Online Draft This draft is a partial preview of what may eventually become a book. The idea is to share it with the public and obtain feedback to improve its quality. So, if you read the whole draft, or maybe just a chapter, or you just glance over it long enough to spot a typo, let me know! I’m interested in all comments and suggestions for improvement, including (natural) language issues, programming, book structure, etc. I would like to thank all the students who have attended my Programming Languages class, during the past 11 years. They taught me that there is no limit to the number of ways you may think to have solved a Java assignment. Naples, Italy Marco Faella January 2018 iii Contents Contents iv I Preliminaries 1 1 Introduction 3 1.1 Software Qualities . 5 2 Problem Statement 9 2.1 Data Model and Representations . 10 3 Hello World! 13 4 Reference Implementation 17 4.1 Space Complexity . 21 4.2 Time Complexity . 23 II Software Qualities 29 5 Need for Speed 31 5.1 Optimizing “getAmount” and “addWater” . 32 5.2 Optimizing “connectTo” and “addWater” . 34 5.3 The Best Balance: Union-Find Algorithms .
    [Show full text]
  • Closure Joinpoints: Block Joinpoints Without Surprises
    Closure Joinpoints: Block Joinpoints without Surprises Eric Bodden Software Technology Group, Technische Universität Darmstadt Center for Advanced Security Research Darmstadt (CASED) [email protected] ABSTRACT 1. INTRODUCTION Block joinpoints allow programmers to explicitly mark re- In this work, we introduce Closure Joinpoints for As- gions of base code as \to be advised", thus avoiding the need pectJ [6], a mechanism that allows programmers to explicitly to extract the block into a method just for the sake of cre- mark any Java expression or sequence of statement as \to ating a joinpoint. Block joinpoints appear simple to define be advised". Closure Joinpoints are explicit joinpoints that and implement. After all, regular block statements in Java- resemble labeled, instantly called closures, i.e., anonymous like languages are constructs well-known to the programmer inner functions with access to their declaring lexical scope. and have simple control-flow and data-flow semantics. As an example, consider the code in Figure1, adopted Our major insight is, however, that by exposing a block from Hoffman's work on explicit joinpoints [24]. The pro- of code as a joinpoint, the code is no longer only called in grammer marked the statements of lines4{8, with a closure its declaring static context but also from within aspect code. to be \exhibited" as a joinpoint Transaction so that these The block effectively becomes a closure, i.e., an anonymous statements can be advised through aspects. Closure Join- function that may capture values from the enclosing lexical points are no first-class objects, i.e., they cannot be assigned scope.
    [Show full text]
  • Graph Reduction Without Pointers
    Graph Reduction Without Pointers TR89-045 December, 1989 William Daniel Partain The University of North Carolina at Chapel Hill Department of Computer Science ! I CB#3175, Sitterson Hall Chapel Hill, NC 27599-3175 UNC is an Equal Opportunity/Aflirmative Action Institution. Graph Reduction Without Pointers by William Daniel Partain A dissertation submitted to the faculty of the University of North Carolina at Chapel Hill in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science. Chapel Hill, 1989 Approved by: Jfn F. Prins, reader ~ ~<---(­ CJ)~ ~ ;=tfJ\ Donald F. Stanat, reader @1989 William D. Partain ALL RIGHTS RESERVED II WILLIAM DANIEL PARTAIN. Graph Reduction Without Pointers (Under the direction of Gyula A. Mag6.) Abstract Graph reduction is one way to overcome the exponential space blow-ups that simple normal-order evaluation of the lambda-calculus is likely to suf­ fer. The lambda-calculus underlies lazy functional programming languages, which offer hope for improved programmer productivity based on stronger mathematical underpinnings. Because functional languages seem well-suited to highly-parallel machine implementations, graph reduction is often chosen as the basis for these machines' designs. Inherent to graph reduction is a commonly-accessible store holding nodes referenced through "pointers," unique global identifiers; graph operations cannot guarantee that nodes directly connected in the graph will be in nearby store locations. This absence of locality is inimical to parallel computers, which prefer isolated pieces of hardware working on self-contained parts of a program. In this dissertation, I develop an alternate reduction system using "sus­ pensions" (delayed substitutions), with terms represented as trees and vari­ ables by their binding indices (de Bruijn numbers).
    [Show full text]
  • CONS Should Not CONS Its Arguments, Or, a Lazy Alloc Is a Smart Alloc Henry G
    CONS Should not CONS its Arguments, or, a Lazy Alloc is a Smart Alloc Henry G. Baker Nimble Computer Corporation, 16231 Meadow Ridge Way, Encino, CA 91436, (818) 501-4956 (818) 986-1360 (FAX) November, 1988; revised April and December, 1990, November, 1991. This work was supported in part by the U.S. Department of Energy Contract No. DE-AC03-88ER80663 Abstract semantics, and could profitably utilize stack allocation. One would Lazy allocation is a model for allocating objects on the execution therefore like to provide stack allocation for these objects, while stack of a high-level language which does not create dangling reserving the more expensive heap allocation for those objects that references. Our model provides safe transportation into the heap for require it. In other words, one would like an implementation which objects that may survive the deallocation of the surrounding stack retains the efficiency of stack allocation for most objects, and frame. Space for objects that do not survive the deallocation of the therefore does not saddle every program with the cost for the surrounding stack frame is reclaimed without additional effort when increased flexibility--whether the program uses that flexibility or the stack is popped. Lazy allocation thus performs a first-level not. garbage collection, and if the language supports garbage collection The problem in providing such an implementation is in determining of the heap, then our model can reduce the amortized cost of which objects obey LIFO allocation semantics and which do not. allocation in such a heap by filtering out the short-lived objects that Much research has been done on determining these objects at can be more efficiently managed in LIFO order.
    [Show full text]
  • Automatically Achieving Elasticity in the Implementation of Programming Languages Michael Lee Horowitz
    Automatically Achieving Elasticity in the Implementation of Programming Languages Michael Lee Horowitz January 1988 CMU-CS-88- I04 Submitted to CarnegieMellon Universityin partial fulf'dlment of the requirements for the degree of Doctor of Philosophy in Computer Science. Department of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Copyright © 1988 Michael Lee Horowitz. All fights reserved. This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976 under contract F33615-87-C-1499 and monitored by the: Avionics Laboratory Air Force Wright Aeronautical Laboratories Aeronautical Systems Division (AFSC) Wright-Patterson AFB, OHIO 45433-6543 The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. Abstract Several developments in programming language design and software engineering lead to a re- examination of the role of binding times in programming language implementation. We can alleviate problems associated with these developments by using event-driven processing to determine translation binding times. Our ultimate goal is to clarify the effects of different designs on binding times and to reduce binding time concerns in the language design process. Determining the binding time of a translation action involves two concerns: the ordering of the action's execution relative to other actions and the translation phase in which the execution occurs (e.g. compile- time, link-time, or run-time). Some issues that affect these concerns include: how to handle forward references, language designs that require dynamic interpretation, the role of link-time in languages that allow separate compilation, and how to achieve elasticity.
    [Show full text]
  • Tamperproofing a Software Watermark by Encoding Constants
    Tamperproofing a Software Watermark by Encoding Constants by Yong He A Thesis Submitted in Partial Fulfilment of the Requirement for the Degree of MASTER OF SCIENCE in Computer Science University of Auckland Copyright © 2002 by Yong He i Abstract Software Watermarking is widely used for software ownership authentication, but it is susceptible to various de-watermarking attacks such as obfuscation. Dynamic Graph Watermarking is a relatively new technology for software watermarking, and is believed the most likely to withstand attacks, which are trying to distort watermark structure. In this thesis, we present a new technology for protecting Dynamic Graph Watermarks. This technology encodes some of the constants, which are found in a software program, into a tree structure that is similar to the watermark, and generates decoding functions to retrieve the value of the constants at program execution time. If the constant tree is modified, the value of some constants will be affected, destroying program correctness. An attacker cannot reliably distinguish the watermark tree from the constant tree, so they must preserve the watermark tree or risk introducing bugs into the program. Constant Encoding technology can be included in Dynamic Graph Watermarking systems as a plug-in module to improve the Dynamic Graph Watermark protection. In this thesis, we present a prototyping program for Constant Encoding technology, which we call the JSafeMark encoder. Besides addressing the issues about Constant Encoding technology, we also discuss the design and implementation of our JSafeMark encoder, and give a practical example to show how this technology can protect Dynamic Graph Watermarking. iii Acknowledgement I would like to thank Professor Clark Thomborson, my supervisor, for his guidance and enthusiasm.
    [Show full text]
  • N4397: a Low-Level API for Stackful Coroutines
    Document number: N4397 Date: 2015-04-09 Project: WG21, SG1 Author: Oliver Kowalke ([email protected]) A low-level API for stackful coroutines Abstract........................................................1 Background.....................................................2 Definitions......................................................2 Execution context.............................................2 Activation record.............................................2 Stack frame.................................................2 Heap-allocated activation record....................................2 Processor stack..............................................2 Application stack.............................................3 Thread stack................................................3 Side stack..................................................3 Linear stack................................................3 Linked stack................................................3 Non-contiguous stack..........................................3 Parent pointer tree............................................3 Coroutine.................................................3 Toplevel context function.........................................4 Asymmetric coroutine..........................................4 Symmetric coroutine...........................................4 Fiber/user-mode thread.........................................4 Resumable function............................................4 Suspend by return.............................................4 Suspend
    [Show full text]
  • Dynamic Graph-Based Software Watermarking
    Dynamic Graph-Based Software Watermarking † ‡ Christian Collberg∗, Clark Thomborson, Gregg M. Townsend Technical Report TR04-08 April 28, 2004 Abstract Watermarking embeds a secret message into a cover message. In media watermarking the secret is usually a copyright notice and the cover a digital image. Watermarking an object discourages intellectual property theft, or when such theft has occurred, allows us to prove ownership. The Software Watermarking problem can be described as follows. Embed a structure W into a program P such that: W can be reliably located and extracted from P even after P has been subjected to code transformations such as translation, optimization and obfuscation; W is stealthy; W has a high data rate; embedding W into P does not adversely affect the performance of P; and W has a mathematical property that allows us to argue that its presence in P is the result of deliberate actions. In this paper we describe a software watermarking technique in which a dynamic graph watermark is stored in the execution state of a program. Because of the hardness of pointer alias analysis such watermarks are difficult to attack automatically. 1 Introduction Steganography is the art of hiding a secret message inside a host (or cover) message. The purpose is to allow two parties to communicate surreptitiously, without raising suspicion from an eavesdropper. Thus, steganography and cryptog- raphy are complementary techniques: cryptography attempts to hide the contents of a message while steganography attempts to hide the existence of a message. History provides many examples of steganographic techniques used in the military and intelligence communities.
    [Show full text]
  • Functional Programming Is Free
    Functional Programming is Free. Francis Sergeraert January 2015 Abstract A paper [5] has recently been published. This paper is faulty: 1) The standard requirements about the definition of an algorithm are not respected, 2) The main point in the complexity study, namely the functional programming component, is absent. The Editorial Board of the SIAM JC had been warned a confirmed publication would be openly commented, it is the role of this text1. 1 History of the subject. I started the subject of Effective Homology in 1984, trying first to implement the Edgar Brown’s “algorithm” [4] computing the homotopy groups of the finite simply connected simplicial sets. This idea was quickly understood as ridiculous; thirty years later, there remains difficult to hope for an actual implementation of this algorithm, much too complex. Other methods were soon imagined to overcome the essential difficulty, con- sisting in using the strange power of the functional programming. Julio Rubio’s contribution was essential to make the project succeed: he understood in 1989 that the best theoretical tool to organize the work is the so-called Basic Perturbation Lemma [9, 3], more and more often called now the Homological Perturbation The- orem, you may question Google(Galway perturbation) to see numerous examples. Using Julio’s idea, a program called EAT (Effective Algebraic Topology) was soon obtained in 1990, mainly devoted to the computation of the homology groups of iterated loop spaces, already allowing us to produce homology groups so far arXiv:1504.00527v1 [cs.PL] 2 Apr 2015 unreachable by the “standard” methods. In the years 1995-8, Xavier Dousson’s thesis was devoted to the calculation of homotopy groups; the same tools, functional programming combined with the homological perturbation theorem, were successfully applied to the so-called White- head and Postnikov towers, the most “elementary” methods to compute the ho- motopy groups.
    [Show full text]