DOCSLIB.ORG

The Theory and Practice of First-Class Prompts

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Theory and Practice of First-Class Prompts The Theory and Practice of First-Class Prompts Mat t hias Felleisen Indiana University Computer Science Department Lindley Hall 101 Bloomington, IN 47405 Abstract. An analysis of the X,-C-calculus and in the calculus do not necessarily behave equivalently its problematic relationship to operational equiva- in all program contexts. The problem can be fixed lence leads to a new control facility: the promp& with a meta-theorem that distinguishes theorems in application. With the introduction of prompt- the theory as operational equalities, yet, this is not a applications, the control calculus becomes a tradi- desirable situation. tional calculus all of whose equations imply opera- In this paper, we present a different and more tional equivalence. In addition, prompt-applications promising solution. It is baaed on a new linguistic enhance the expressiveness and efficiency of the lan- facility for constraining the extent of control opera- guage. We illustrate the latter claim with examples tions: the prompt-application. The introduction of from such distinct areas as systems programming and prompt-applications transforms the control calculus tree processing. into a truly traditional calculus, an.d, in addition, prompt-applications are a practical tool for a broad variety of programming paradigms. We illustrate the latter claim with examples from such distinct areas 1 A Problem of the X,-C- as systems programming and tree processing. In the next section, we formalize the original X,- calculus C-calculus and the concept of a first-class prompt facility. We then show that the extended calculus The X,-C-calculus [2, 43 is a conservative extension is consistent and that there is a standard reduction of Plotkin’s &-calculus [ll] for reasoning about im- function. Based on this, we define an operational perative control operations in call-by-value languages. semantics and show that theorems in the calculus di- The theory satisfies modified versions of the Church- rectly imply operational equivalence. The third sec- Rosser and the Curry-Feys Standardization Theorem. tion contains an abstract stack-machine for the ex- Furthermore, the standardization procedure yields tended language and a brief discussion of the im- the same answers for programs as the evaluation func- plementation cost. Section 4 is a collection of pro- tion of an ap:propriate abstract machine. However, gramming examples, which illustrates the expressive the calculus also has a major deficiency: equality in power of prompt-applications. The fifth section is the calculus does no2 imply operational equality on an overview of related work. In the conclusion, we the machine. That is, two expressions that are equal analyze the contribution of language calculi to the “This work was partly supported by an IBM Fellowship and systematic analysis of programming :languages. Dan FEedman’s NSF grant (DCR 85 01277). Author’s cursent &dress: Rice University, Herrman Brown Hall, Houston, TX 77251-1892 2 The modified X,-C-calculus The term set A7 of the original X,-C-calculus is de- fined inductively over a set of algebraic constants, Con& and a set of variables, Vars: Permission to copy without fee all or part of this material is granted L ::= a 12 1 Xt.M 1 MN 1 FM, provided that the copies are not made or distributed for direct commercial advantage, the. ACM copyright notice and the title of the publication and its date appear, and notice is given that copying where a ranges over constants, xover Vars, and L, M, is by permission of the Association for Computing Machinery. To and Nover &-terms. The first four classes of expres- copy otherwise, or to republish, requires a fee and/or specfic permission. Proceedings of the Fifteenth Annual ACM SIGACT-SIGPLAN Symposium on Princi- @ 1988 ACM-O-89791-252-7/88/0001/0180 $1.50 180 sions have their original semantics: constants stand 3Jr: V(3’M) - 3(Ak.M(Am.k(Vm))) for basic and functional constants from some kind provided V is a value. of algebraic domain, variables are placeholders, A- abstractions represent call-by-value procedures, and combinations denote function applications. The purpose of these reductions is to push an 3-app- As usual, the variable 3: in the abstraction Xt.M is lication to the root of a term and to encode the con- called the bound variable; a variable that is not bound text of the 3-application as an abstraction. Once the by some X is free. An expression with no free variables 3-application has reached the root, the computation is called closed. Programs in this language are closed relation expressions. Like Barendregt [1:26], we identify terms 3’M D kf(h.z) that are identical modulo bound variables, and we assume that free and bound variables cannot interfere eliminates the 3-application by applying the 3- with each other. The substituion of a free variable 2: argument to the identity function, a representation by N in a term M is denoted by M[z := N]. of the empty context. The computation rule is de- The new expression type is called 3-application,’ noted with D instead of the customary - because it its subterm is an 3-argument. An 3-application can only be applied to the root: an unrestricted use transforms the current control state into a functional would make the calculus inconsistent. abstr&ion, which we call continuation.2 Next, the The nature of 3-applications and continuations is 3-application applies its argument to this continua- best illustrated with examples. Consider the program tion, thus providing the 3-argument with total power (1+(3(Xd.O))). It evaluates to 0 after the 3-applica- over the rest of the computation. In particular, if the tion erases the call to l+: corresponding actions are to be performed at all, the 3-argument must invoke this continuation. (~+vww) - T(M.(Ad.O)(Av.lc(l+v))) The equational theory is specified with a set of term D (~k.((~~.o)(h.k(1+~))))(xz.+) relations for the evaluation of expressions. Constants, - (Mo)(xV.(xz!.~)(l+?J)) variables, and X-abstractions require no further evalu- ation and are appropriately referred to as values. For - 0. the evaluation of an application of a function con- stant to a basic constant, we assume the existence of an interpretation 6 on the set of constants: Put more abstractly, 3(Ad.V) where d does not occur in the value V behaves like an abort operation that S: FuncConst x BasicConst -w Closed-A- Values. returns V. The conventional goto is a straightforward generalization of abort. If we replace the value V The b-reduction for constant applications is: with an arbitrary expression M, the term S(Xd.M) 6: fa - b(f, a). first eliminates the current state and then installs M as the new one. The evaluation of an application of a X-abstraction to When a continuation is applied, it acts like an or- a value is determined by the ,&value relation: dinary function. It performs the encoded rest of the computation and, unless an 3-application intervenes, p: (A;c.M)V - M[z: := V] provided V is a value. returns to the point of invocation: That is, an application whose first part is an abstrac- (1+(3(Xk.(k(kO))))) tion and whose second part is a value is reduced to - (3(X~.(~~.(@O)))(Xz.E(1+2))) a term that is like the function body with all oc- currences of the abstracted variable replaced by the D (Ak.((Ak.(k(kO)))(Xz.k(l+x))))(Az.z) value. - ((~~.(k(rco)))(~zc.(xz.z)(l+~))) The meaning of 3-applications is determined by - ((~z!.(~z.~)(l+z))((xz.(~z.z)(l+2?))o)) two reductions and a special computation relation. - ((~zY(~~.~)(1+~))((xz.z!)(1+0))) The reductions are: - ((xz.(~z.~)(1+2?))1) 3L: (3M)N - 3(Ak.A!r(Am.k(nzlv))), - (xz.z)(l+l) ‘3- is a generalized version of Iswim’s J [s], Reynolds’s es- - (>2.2)2 cape [13], and Scheme’s [12] call/cc. -3 2. 2WARNING: This usage is inconsistent with Scheme- , terminology. 181 The problem of this calculus is the separation of With this modification, the X,-C-calculus becomes computation and reduction relations. Since compu- a calculus in the traditional sense: tation relations can only be applied at the root of Definition. (The new &-C-calculus) The basic no- a term, an equation that is based on the compula- tion of reduction c collects all of the above relations: lion relation does not imply operational equivalence. More precisely, even if two terms are computation- ally equivalent, there are generally program contexts The one-step c-reduction, -c, is the compatible clo- that can distinguish the two expressions. A typical sure of c: example is the pair of terms 3(Ad.O) and 0. Al- though equivalent according to the computation rela- (M,N)- d M-,N tion, they behave differently in practically all con- M-,N + Xz.M-Jx.N texts. Whereas the former aborts a computation when evaluated, the second one simply evaluates to 0. M-,N + 3M-,3N A possible and obvious fix is the introduction of M-,N =+ #M-,#N a unique top-level marker # for identifying the root M-,N + LM---+,LN, MLA--+,NL; of a program. Then the computation relation can be replaced by a reduction relation: -+e stands for the transitive-reflexive closure of the #3: (# (3M)) - (# (M(Xx.x))). one-step c-reduction. However, this solution pushes the semantic division The c-congruence is defined as: into the language syntax and does not eliminate the complications of its predecessor: equations for #- M =:c M contained terms cannot predict the behavior of these M-,N =S M=:, N terms in arbitratry contexts.
Load more

Recommended publications
  • How to Design Co-Programs
    JFP, 15 pages, 2021. c Cambridge University Press 2021 1 doi:10.1017/xxxxx EDUCATIONMATTERS How to Design Co-Programs JEREMY GIBBONS Department of Computer Science, University of Oxford e-mail: [email protected] Abstract The observation that program structure follows data structure is a key lesson in introductory pro- gramming: good hints for possible program designs can be found by considering the structure of the data concerned. In particular, this lesson is a core message of the influential textbook “How to Design Programs” by Felleisen, Findler, Flatt, and Krishnamurthi. However, that book discusses using only the structure of input data for guiding program design, typically leading towards structurally recur- sive programs. We argue that novice programmers should also be taught to consider the structure of output data, leading them also towards structurally corecursive programs. 1 Introduction Where do programs come from? This mystery can be an obstacle to novice programmers, who can become overwhelmed by the design choices presented by a blank sheet of paper, or an empty editor window— where does one start? A good place to start, we tell them, is by analyzing the structure of the data that the program is to consume. For example, if the program h is to process a list of values, one may start by analyzing the structure of that list. Either the list is empty ([]), or it is non-empty (a : x) with a head (a) and a tail (x). This provides a candidate program structure: h [ ] = ::: h (a : x) = ::: a ::: x ::: where for the empty list some result must simply be chosen, and for a non-empty list the result depends on the head a and tail x.
    [Show full text]
  • Final Shift for Call/Cc: Direct Implementation of Shift and Reset
    Final Shift for Call/cc: Direct Implementation of Shift and Reset Martin Gasbichler Michael Sperber Universitat¨ Tubingen¨ fgasbichl,[email protected] Abstract JxKρ = λk:(k (ρ x)) 0 0 We present a direct implementation of the shift and reset con- Jλx:MKρ = λk:k (λv:λk :(JMK)(ρ[x 7! v]) k ) trol operators in the Scheme 48 system. The new implementation JE1 E2Kρ = λk:JE1Kρ (λ f :JE2Kρ (λa: f a k) improves upon the traditional technique of simulating shift and reset via call/cc. Typical applications of these operators exhibit Figure 1. Continuation semantics space savings and a significant overall performance gain. Our tech- nique is based upon the popular incremental stack/heap strategy for representing continuations. We present implementation details as well as some benchmark measurements for typical applications. this transformation has a direct counterpart as a semantic specifica- tion of the λ calculus; Figure 1 shows such a semantic specification for the bare λ calculus: each ρ is an environment mapping variables Categories and Subject Descriptors to values, and each k is a continuation—a function from values to values. An abstraction denotes a function from an environment to a D.3.3 [Programming Languages]: Language Constructs and Fea- function accepting an argument and a continuation. tures—Control structures In the context of the semantics, the rule for call/cc is this: General Terms Jcall=cc EKρ = λk:JEKρ (λ f : f (λv:λk0:k v) k) Languages, Performance Call=cc E evaluates E and calls the result f ; it then applies f to an Keywords escape function which discards the continuation k0 passed to it and replaces it by the continuation k of the call=cc expression.
    [Show full text]
  • (Pdf) of from Push/Enter to Eval/Apply by Program Transformation
    From Push/Enter to Eval/Apply by Program Transformation MaciejPir´og JeremyGibbons Department of Computer Science University of Oxford [email protected] [email protected] Push/enter and eval/apply are two calling conventions used in implementations of functional lan- guages. In this paper, we explore the following observation: when considering functions with mul- tiple arguments, the stack under the push/enter and eval/apply conventions behaves similarly to two particular implementations of the list datatype: the regular cons-list and a form of lists with lazy concatenation respectively. Along the lines of Danvy et al.’s functional correspondence between def- initional interpreters and abstract machines, we use this observation to transform an abstract machine that implements push/enter into an abstract machine that implements eval/apply. We show that our method is flexible enough to transform the push/enter Spineless Tagless G-machine (which is the semantic core of the GHC Haskell compiler) into its eval/apply variant. 1 Introduction There are two standard calling conventions used to efficiently compile curried multi-argument functions in higher-order languages: push/enter (PE) and eval/apply (EA). With the PE convention, the caller pushes the arguments on the stack, and jumps to the function body. It is the responsibility of the function to find its arguments, when they are needed, on the stack. With the EA convention, the caller first evaluates the function to a normal form, from which it can read the number and kinds of arguments the function expects, and then it calls the function body with the right arguments.
    [Show full text]
  • Stepping Ocaml
    Stepping OCaml TsukinoFurukawa YouyouCong KenichiAsai Ochanomizu University Tokyo, Japan {furukawa.tsukino, so.yuyu, asai}@is.ocha.ac.jp Steppers, which display all the reduction steps of a given program, are a novice-friendly tool for un- derstanding program behavior. Unfortunately, steppers are not as popular as they ought to be; indeed, the tool is only available in the pedagogical languages of the DrRacket programming environment. We present a stepper for a practical fragment of OCaml. Similarly to the DrRacket stepper, we keep track of evaluation contexts in order to reconstruct the whole program at each reduction step. The difference is that we support effectful constructs, such as exception handling and printing primitives, allowing the stepper to assist a wider range of users. In this paper, we describe the implementationof the stepper, share the feedback from our students, and show an attempt at assessing the educational impact of our stepper. 1 Introduction Programmers spend a considerable amount of time and effort on debugging. In particular, novice pro- grammers may find this process extremely painful, since existing debuggers are usually not friendly enough to beginners. To use a debugger, we have to first learn what kinds of commands are available, and figure out which would be useful for the current purpose. It would be even harder to use the com- mand in a meaningful manner: for instance, to spot the source of an unexpected behavior, we must be able to find the right places to insert breakpoints, which requires some programming experience. Then, is there any debugging tool that is accessible to first-day programmers? In our view, the algebraic stepper [1] of DrRacket, a pedagogical programming environment for the Racket language, serves as such a tool.
    [Show full text]
  • Practical Ruby Projects: Practical Ruby Projects Ideas for the Eclectic Programmer
    CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN OPEN SOURCE Companion eBook Available Practical Ruby Projects: Projects Ruby Practical Ideas for the Eclectic Programmer Dear Reader, You’ve learned the basics of Ruby, and you’re ready to move on to the next level— trying out advanced techniques, mastering best practices, and exploring Ruby’s full potential. With this book you’ll learn by experience while you tackle an exciting series of varied but always practical programming projects. What is an eclectic programmer, you ask? He or she is an inquisitive thinker Practical who likes to play around with new concepts, a person who is project-oriented and enjoys coding, a person who doesn’t mind some technical depth folded in with creative excursions, and a person who is always looking for fresh ideas. This book is a little different from other computer books. It is meant to be entertaining, exciting, and intellectually challenging. Inside you’ll find a collec- tion of diverse projects, ranging from the creative to the practical, written as a nod to all the great Rubyists I’ve been privileged to know. Each chapter dives into Ruby Projects new topics and approaches meant to exercise your programming muscles. You’ll start by building a cross-platform music environment, progress to drawing animations using scalable vector graphics, and then move on to prac- tical problem solving using simulation. In addition, you’ll implement your own turn-based strategy game and build a Mac-native RubyCocoa interface to it.
    [Show full text]
  • A Practical Introduction to Python Programming
    A Practical Introduction to Python Programming Brian Heinold Department of Mathematics and Computer Science Mount St. Mary’s University ii ©2012 Brian Heinold Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported Li- cense Contents I Basics1 1 Getting Started 3 1.1 Installing Python..............................................3 1.2 IDLE......................................................3 1.3 A first program...............................................4 1.4 Typing things in...............................................5 1.5 Getting input.................................................6 1.6 Printing....................................................6 1.7 Variables...................................................7 1.8 Exercises...................................................9 2 For loops 11 2.1 Examples................................................... 11 2.2 The loop variable.............................................. 13 2.3 The range function............................................ 13 2.4 A Trickier Example............................................. 14 2.5 Exercises................................................... 15 3 Numbers 19 3.1 Integers and Decimal Numbers.................................... 19 3.2 Math Operators............................................... 19 3.3 Order of operations............................................ 21 3.4 Random numbers............................................. 21 3.5 Math functions............................................... 21 3.6 Getting
    [Show full text]
  • Making a Faster Curry with Extensional Types
    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
    [Show full text]
  • Advanced Tcl E D
    PART II I I . A d v a n c Advanced Tcl e d T c l Part II describes advanced programming techniques that support sophisticated applications. The Tcl interfaces remain simple, so you can quickly construct pow- erful applications. Chapter 10 describes eval, which lets you create Tcl programs on the fly. There are tricks with using eval correctly, and a few rules of thumb to make your life easier. Chapter 11 describes regular expressions. This is the most powerful string processing facility in Tcl. This chapter includes a cookbook of useful regular expressions. Chapter 12 describes the library and package facility used to organize your code into reusable modules. Chapter 13 describes introspection and debugging. Introspection provides information about the state of the Tcl interpreter. Chapter 14 describes namespaces that partition the global scope for vari- ables and procedures. Namespaces help you structure large Tcl applications. Chapter 15 describes the features that support Internationalization, includ- ing Unicode, other character set encodings, and message catalogs. Chapter 16 describes event-driven I/O programming. This lets you run pro- cess pipelines in the background. It is also very useful with network socket pro- gramming, which is the topic of Chapter 17. Chapter 18 describes TclHttpd, a Web server built entirely in Tcl. You can build applications on top of TclHttpd, or integrate the server into existing appli- cations to give them a web interface. TclHttpd also supports regular Web sites. Chapter 19 describes Safe-Tcl and using multiple Tcl interpreters. You can create multiple Tcl interpreters for your application. If an interpreter is safe, then you can grant it restricted functionality.
    [Show full text]
  • CSE341, Fall 2011, Lecture 17 Summary
    CSE341, Fall 2011, Lecture 17 Summary Standard Disclaimer: This lecture summary is not necessarily a complete substitute for attending class, reading the associated code, etc. It is designed to be a useful resource for students who attended class and are later reviewing the material. This lecture covers three topics that are all directly relevant to the upcoming homework assignment in which you will use Racket to write an interpreter for a small programming language: • Racket's structs for defining new (dynamic) types in Racket and contrasting them with manually tagged lists [This material was actually covered in the \Monday section" and only briefly reviewed in the other materials for this lecture.] • How a programming language can be implemented in another programming language, including key stages/concepts like parsing, compilation, interpretation, and variants thereof • How to implement higher-order functions and closures by explicitly managing and storing environments at run-time One-of types with lists and dynamic typing In ML, we studied one-of types (in the form of datatype bindings) almost from the beginning, since they were essential for defining many kinds of data. Racket's dynamic typing makes the issue less central since we can simply use primitives like booleans and cons cells to build anything we want. Building lists and trees out of dynamically typed pairs is particularly straightforward. However, the concept of one-of types is still prevalent. For example, a list is null or a cons cell where there cdr holds a list. Moreover, Racket extends its Scheme predecessor with something very similar to ML's constructors | a special form called struct | and it is instructive to contrast the two language's approaches.
    [Show full text]
  • Specialising Dynamic Techniques for Implementing the Ruby Programming Language
    SPECIALISING DYNAMIC TECHNIQUES FOR IMPLEMENTING THE RUBY PROGRAMMING LANGUAGE A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences 2015 By Chris Seaton School of Computer Science This published copy of the thesis contains a couple of minor typographical corrections from the version deposited in the University of Manchester Library. [email protected] chrisseaton.com/phd 2 Contents List of Listings7 List of Tables9 List of Figures 11 Abstract 15 Declaration 17 Copyright 19 Acknowledgements 21 1 Introduction 23 1.1 Dynamic Programming Languages.................. 23 1.2 Idiomatic Ruby............................ 25 1.3 Research Questions.......................... 27 1.4 Implementation Work......................... 27 1.5 Contributions............................. 28 1.6 Publications.............................. 29 1.7 Thesis Structure............................ 31 2 Characteristics of Dynamic Languages 35 2.1 Ruby.................................. 35 2.2 Ruby on Rails............................. 36 2.3 Case Study: Idiomatic Ruby..................... 37 2.4 Summary............................... 49 3 3 Implementation of Dynamic Languages 51 3.1 Foundational Techniques....................... 51 3.2 Applied Techniques.......................... 59 3.3 Implementations of Ruby....................... 65 3.4 Parallelism and Concurrency..................... 72 3.5 Summary............................... 73 4 Evaluation Methodology 75 4.1 Evaluation Philosophy
    [Show full text]
  • Language Design and Implementation Using Ruby and the Interpreter Pattern
    Language Design and Implementation using Ruby and the Interpreter Pattern Ariel Ortiz Information Technology Department Tecnológico de Monterrey, Campus Estado de México Atizapán de Zaragoza, Estado de México, Mexico. 52926 [email protected] ABSTRACT to explore different language concepts and programming styles. In this paper, the S-expression Interpreter Framework (SIF) is Section 4 describes briefly how the SIF has been used in class. presented as a tool for teaching language design and The conclusions are found in section 5. implementation. The SIF is based on the interpreter design pattern and is written in the Ruby programming language. Its core is quite 1.1 S-Expressions S-expressions (symbolic expressions) are a parenthesized prefix small, but it can be easily extended by adding primitive notation, mainly used in the Lisp family languages. They were procedures and special forms. The SIF can be used to demonstrate selected as the framework’s source language notation because advanced language concepts (variable scopes, continuations, etc.) they offer important advantages: as well as different programming styles (functional, imperative, and object oriented). • Both code and data can be easily represented. Adding a new language construct is pretty straightforward. • Categories and Subject Descriptors The number of program elements is minimal, thus a parser is − relatively easy to write. D.3.4 [Programming Languages]: Processors interpreters, • run-time environments. The arity of operators doesn’t need to be fixed, so, for example, the + operator can be defined to accept any number of arguments. General Terms • There are no problems regarding operator precedence or Design, Languages. associativity, because every operator has its own pair of parentheses.
    [Show full text]
  • Functional Programming Lecture 1: Introduction
    Functional Programming Lecture 4: Closures and lazy evaluation Viliam Lisý Artificial Intelligence Center Department of Computer Science FEE, Czech Technical University in Prague [email protected] Last lecture • Functions with variable number of arguments • Higher order functions – map, foldr, foldl, filter, compose Binding scopes A portion of the source code where a value is bound to a given name • Lexical scope – functions use bindings available where defined • Dynamic scope – functions use bindings available where executed Ben Wood's slides Eval Eval is a function defined in the top level context (define x 5) (define (f y) (eval '(+ x y))) Fails because of lexical scoping Otherwise the following would be problematic (define (eval x) (eval-expanded (macro-expand x))) Eval in R5RS (eval expression environment) Where the environment is one of (interaction-environment) (global defines) (scheme-report-environment x) (before defines) (null-environment x) (only special forms) None of them allows seeing local bindings Cons (define (my-cons x y) (lambda (m) (m x y))) (define (my-car p) (p (lambda (x y) x))) (define (my-cdr s) (p (lambda (x y) y))) Currying Transforms function to allow partial application not curried 푓: 퐴 × 퐵 → 퐶 curried 푓: 퐴 → (퐵 → 퐶) not curried 푓: 퐴 × 퐵 × 퐶 → 퐷 curried 푓: 퐴 → (퐵 → 퐶 → 퐷 ) Picture: Haskell Curry from Wikipedia Currying (define (my-curry1 f) (lambda args (lambda rest (apply f (append args rest))))) (define (my-curry f) (define (c-wrap f stored-args) (lambda args (let ((all (append stored-args args)))
    [Show full text]