Functional Programming February 25, 2019 Functional Programming February 25, 2019 1 / 63 Mayer Goldberg \ Ben-Gurion University Mayer Goldberg \ Ben-Gurion University
Functional Programming Contact information February 25, 2019 2 / 63 ▶ Mayer Goldberg ▶ Email: gmayer@little-lisper.org ▶ Offjce Hours: Mondays, 14-16 (37:106), just before class ▶ Phone: 055-6603392 (cellular) Mayer Goldberg \ Ben-Gurion University
Deliverables Functional Programming February 25, 2019 3 / 63 ▶ Homework: 20% ▶ Final exam: 70% ▶ Class participation: 10% Mayer Goldberg \ Ben-Gurion University
Road Map Functional Programming February 25, 2019 4 / 63 ☞ Introduction to Functional Programming ▶ λ -Defjnability ▶ Tuples & RTTI ▶ Bases ▶ Fixed-Point Theory ▶ Functions as Data ▶ Streams ▶ Maps & Folds ▶ CPS & Threading Code ▶ Monads ▶ Possibly additional topics, depending on time Mayer Goldberg \ Ben-Gurion University
Chapter 1 Goals Agenda Functional Programming February 25, 2019 5 / 63 ▶ Understanding the ”big picture” ▶ Establishing common language & vocabulary ▶ Imperative programming ▶ Functional programming ▶ The advantages of functional programming Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages PPL & compiler construction courses side efgects Defjning a language in terms of what it is not doesn’t teach us much. Functional Programming February 25, 2019 6 / 63 ▶ You’ve already been exposed to functional programming in your ▶ Functional languages are often described as languages lacking in ▶ Imperative languages have side efgects ▶ What can we say positively about functional programming? Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) electrical engineering Computers their outputs to memory frequency measured in Hz, KHz, MHz, GHz…) Functional Programming February 25, 2019 7 / 63 ▶ Computer science is the illegitimate child of mathematics and ▶ Electrical engineering gave us the hardware , the actual machine ▶ Nearly all ideas come from mathematics ▶ Digital electronics: Gates, fmip-fmops, latches, memory, etc ▶ Boolean functions that read their inputs from memory & write ▶ Reading & writing are synchronized using a clock (with a ▶ A fjnite-state machine Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) level of digital electronics computation mathematics to help us program better Functional Programming February 25, 2019 8 / 63 ▶ We cannot design large software systems while thinking at the ▶ We need some theoretical foundation for programming & ▶ Such a theoretical foundation should enable us to use tools from Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) What is mathematics? expressed in this language What computer science takes from mathematics? In short: Everything! Functional Programming February 25, 2019 9 / 63 ▶ A language ▶ A set of ideas, notions, defjnitions, techniques, results, all ▶ Programming is based on a computable mathematics ▶ Theoretical computer science uses all of mathematics Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) What programming languages take from mathematics? numbers , types , sets , ordered n tuples , structures , etc tuples, sets, etc), abstraction, mapping, folding, etc. Nearly all of the ideas in computer science come from mathematics! Functional Programming February 25, 2019 10 / 63 ▶ A language ▶ Notions such as functions , variables , expressions , evaluation , ▶ Operations such as arithmetic , Boolean , structural (e.g., on n Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Mathematical objects are free of the limitations that beset computers: Real-world compromises physical computer: Functional Programming February 25, 2019 11 / 63 ▶ Computers can only approximate real numbers ▶ Computers cannot implement infjnite tape ( Turing machines ) ▶ Mathematical objects are cheaper than objects created on a ▶ Functions are mappings; They take no time! ▶ Knowing that an object exists is often all we need! ▶ Bad things cannot happen: ▶ No exceptions , errors , incorrect results ▶ Nothing is lost, nothing is ”too big” or ”too much” Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Functional programming languages Imperative programming languages Functional Programming February 25, 2019 12 / 63 ▶ Closer to mathematics ▶ Easier to reason about ▶ Easier to transform ▶ Easier to generate automatically ▶ Farther from mathematics ▶ Harder to reason about ▶ Harder to transform ▶ Harder to generate automatically Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Example of non-mathematical ideas: Side efgects Imagine having to teach C programming to a logician string -> int that returns the number of characters in the string Functional Programming February 25, 2019 13 / 63 ▶ You teach them a simplifjed version of printf : ▶ Only takes a single string argument ▶ Returns an int : the number of characters in the string ▶ Roughly: printf : string -> int ▶ But the logician objects: He already knows of a function from ▶ strlen : string -> int ▶ He wants to know the difgerence between printf and strlen Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) right?” February 25, 2019 Functional Programming printf !” Side efgects: The Dialogue 14 / 63 the screen & also returns the number of characters it printed!” ▶ You: ”Simple, printf also prints the string to the screen!” ▶ Logician: ”What does it mean to print ??” ▶ You: ”Seriously?? The printf function prints its argument to ▶ Logician: ”But you said the domain of printf is string -> int , ▶ You: ”Yes, so?” ▶ Logician: ”Then where’s the screen??” ▶ You: ”In front of you!” ▶ Logician: ”Where’s the screen in the domain of the function Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Side efgects: The Dialogue ( continued ) February 25, 2019 Functional Programming domain of printf all wrong!” efgect : It is not expressed in the type!” not expressed in the domain of the function??” be a variable when it’s not passed as a parameter, and its type is global variable .” 15 / 63 ▶ You: ”It isn’t in the domain. You can think of the screen as a ▶ Logician: ”I have no idea what you mean: How can the screen ▶ You: ”But that’s the whole point of this printing being a side ▶ Logician: ”Well, then printf isn’t a function!” ▶ You: ”Ummm…” ▶ Logician (having a Eureka!-moment): ”I get it now! You got the Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) an illusion of change, as if the environment has changed: An February 25, 2019 Functional Programming been mapped into another screen in the range. the function call Side efgects from a logical point of view 16 / 63 written explicitly in the original type given for printf ▶ The real type of printf is string × screen → int × screen ▶ The underlined parts of the type are implicit, i.e., they are not ▶ The implicit parts of the type form the environment ▶ The function call mentions only the explicit arguments ▶ Leaving out the implicit arguments in the function call creates illusory notion of time has been created; We have the environment before the function call, and the environment after ▶ In fact, nothing has changed: The screen in the domain has Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Side efgects from a logical point of view ( continued ) February 25, 2019 Functional Programming ”ordering” matters! screen object in the domain of printf("world!\n"); 17 / 63 } printf("world!\n"); printf("Hello "); { ▶ Introducing side efgects introduces discrete time ▶ Having introduced time, we must now introduce sequencing: ▶ The notion of sequencing is, like time, illusory: ▶ The screen object in the range of printf("Hello "); is the ▶ So the two printf expressions are nested, and this is why their Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Functional programming languages computation they are used to implement it on a real computer!) Functional Programming February 25, 2019 18 / 63 ▶ Closer to the mathematical notions of function, variable, ▶ Nothing is implicit ▶ Easier to reason about ▶ Side efgects are not an explicit part of the language (although ▶ Ofgers many other advantages Mayer Goldberg \ Ben-Gurion University
Imperative vs functional languages ( continued ) Imperative programming languages variable, evaluation convenience) sequences , environment , etc., that require translation before we can reason about them various parts of a software system, making it harder to debug Functional Programming February 25, 2019 19 / 63 ▶ Farther away from the mathematical notions such as function, ▶ Hides information through the use of implicit arguments (for ▶ Harder to reason about: Contains notions such as side efgects , ▶ Abstraction is harder, prone to errors ▶ Side efgects create implicit, knotty inter-dependencies between Mayer Goldberg \ Ben-Gurion University
Recommend
More recommend
