Wearing the hair shirt. A retrospective on Haskell - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Wearing the hair shirt. A retrospective on Haskell, слайд №1

Wearing the hair shirt. A retrospective on Haskell, слайд №2

Wearing the hair shirt. A retrospective on Haskell, слайд №3

Wearing the hair shirt. A retrospective on Haskell, слайд №4

Wearing the hair shirt. A retrospective on Haskell, слайд №5

Wearing the hair shirt. A retrospective on Haskell, слайд №6

Wearing the hair shirt. A retrospective on Haskell, слайд №7

Wearing the hair shirt. A retrospective on Haskell, слайд №8

Wearing the hair shirt. A retrospective on Haskell, слайд №9

Wearing the hair shirt. A retrospective on Haskell, слайд №10

Wearing the hair shirt. A retrospective on Haskell, слайд №11

Wearing the hair shirt. A retrospective on Haskell, слайд №12

Wearing the hair shirt. A retrospective on Haskell, слайд №13

Wearing the hair shirt. A retrospective on Haskell, слайд №14

Wearing the hair shirt. A retrospective on Haskell, слайд №15

Wearing the hair shirt. A retrospective on Haskell, слайд №16

Wearing the hair shirt. A retrospective on Haskell, слайд №17

Wearing the hair shirt. A retrospective on Haskell, слайд №18

Wearing the hair shirt. A retrospective on Haskell, слайд №19

Wearing the hair shirt. A retrospective on Haskell, слайд №20

Wearing the hair shirt. A retrospective on Haskell, слайд №21

Wearing the hair shirt. A retrospective on Haskell, слайд №22

Wearing the hair shirt. A retrospective on Haskell, слайд №23

Wearing the hair shirt. A retrospective on Haskell, слайд №24

Wearing the hair shirt. A retrospective on Haskell, слайд №25

Wearing the hair shirt. A retrospective on Haskell, слайд №26

Wearing the hair shirt. A retrospective on Haskell, слайд №27

Wearing the hair shirt. A retrospective on Haskell, слайд №28

Wearing the hair shirt. A retrospective on Haskell, слайд №29

Wearing the hair shirt. A retrospective on Haskell, слайд №30

Wearing the hair shirt. A retrospective on Haskell, слайд №31

Wearing the hair shirt. A retrospective on Haskell, слайд №32

Wearing the hair shirt. A retrospective on Haskell, слайд №33

Wearing the hair shirt. A retrospective on Haskell, слайд №34

Wearing the hair shirt. A retrospective on Haskell, слайд №35

Wearing the hair shirt. A retrospective on Haskell, слайд №36

Wearing the hair shirt. A retrospective on Haskell, слайд №37

Wearing the hair shirt. A retrospective on Haskell, слайд №38

Wearing the hair shirt. A retrospective on Haskell, слайд №39

Wearing the hair shirt. A retrospective on Haskell, слайд №40

Wearing the hair shirt. A retrospective on Haskell, слайд №41

Wearing the hair shirt. A retrospective on Haskell, слайд №42

Wearing the hair shirt. A retrospective on Haskell, слайд №43

Wearing the hair shirt. A retrospective on Haskell, слайд №44

Wearing the hair shirt. A retrospective on Haskell, слайд №45

Wearing the hair shirt. A retrospective on Haskell, слайд №46

Wearing the hair shirt. A retrospective on Haskell, слайд №47

Wearing the hair shirt. A retrospective on Haskell, слайд №48

Wearing the hair shirt. A retrospective on Haskell, слайд №49

Wearing the hair shirt. A retrospective on Haskell, слайд №50

Wearing the hair shirt. A retrospective on Haskell, слайд №51

Wearing the hair shirt. A retrospective on Haskell, слайд №52

Wearing the hair shirt. A retrospective on Haskell, слайд №53

Wearing the hair shirt. A retrospective on Haskell, слайд №54

Wearing the hair shirt. A retrospective on Haskell, слайд №55

Wearing the hair shirt. A retrospective on Haskell, слайд №56

Wearing the hair shirt. A retrospective on Haskell, слайд №57

Wearing the hair shirt. A retrospective on Haskell, слайд №58

Wearing the hair shirt. A retrospective on Haskell, слайд №59

Wearing the hair shirt. A retrospective on Haskell, слайд №60

Wearing the hair shirt. A retrospective on Haskell, слайд №61

Wearing the hair shirt. A retrospective on Haskell, слайд №62

Wearing the hair shirt. A retrospective on Haskell, слайд №63

Wearing the hair shirt. A retrospective on Haskell, слайд №64

Wearing the hair shirt. A retrospective on Haskell, слайд №65

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Wearing the hair shirt. A retrospective on Haskell. Доклад-сообщение содержит 65 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Wearing the hair shirt A retrospective on Haskell Simon Peyton Jones Microsoft Research, Cambridge

Слайд 2

Описание слайда:

The primoridal soup FPCA, Sept 1987: initial meeting. A dozen lazy functional programmers, wanting to agree on a common language. Suitable for teaching, research, and application Formally-described syntax and semantics Freely available Embody the apparent consensus of ideas Reduce unnecessary diversity Led to...a succession of face-to-face meetings April 1990: Haskell 1.0 report released (editors: Hudak, Wadler)

Слайд 3

Описание слайда:

Timeline

Слайд 4

Описание слайда:

Haskell 98

Слайд 5

Описание слайда:

Reflections on the process The idea of having a fixed standard (Haskell 98) in parallel with an evolving language, has worked really well Formal semantics only for fragments (but see [Faxen2002]) A smallish, rather pointy-headed user-base makes Haskell nimble. Haskell has evolved rapidly and continues to do so. Motto: avoid success at all costs

Слайд 6

Описание слайда:

The price of usefulness Libraries increasingly important: 1996: Separate libraries Report 2001: Hierarchical library naming structure, increasingly populated Foreign-function interface increasingly important 1993 onwards: a variety of experiments 2001: successful effort to standardise a FFI across implementations Any language large enough to be useful is dauntingly complex

Слайд 7

Описание слайда:

Слайд 8

Описание слайда:

Syntax Syntax is not important Parsing is the easy bit of a compiler

Слайд 9

Описание слайда:

Syntax Syntax is not important Syntax is the user interface of a language Parsing is the easy bit of a compiler The parser is often the trickiest bit of a compiler

Слайд 10

Описание слайда:

Good ideas from other languages List comprehensions

Слайд 11

Описание слайда:

Fat vs thin

Слайд 12

Описание слайда:

“Declaration style” Define a function as a series of independent equations

Слайд 13

Описание слайда:

“Expression style” Define a function as an expression

Слайд 14

Описание слайда:

Example (ICFP02 prog comp)

Слайд 15

Описание слайда:

So much for syntax...

Слайд 16

Описание слайда:

What really matters? Laziness Type classes Sexy types

Слайд 17

Описание слайда:

Laziness John Hughes’s famous paper “Why functional programming matters” Modular programming needs powerful glue Lazy evaluation enables new forms of modularity; in particular, separating generation from selection. Non-strict semantics means that unrestricted beta substitution is OK.

Слайд 18

Описание слайда:

But... Laziness makes it much, much harder to reason about performance, especially space. Tricky uses of seq for effect seq :: a -> b -> b Laziness has a real implementation cost Laziness can be added to a strict language (although not as easily as you might think) And it’s not so bad only having V instead of 

Слайд 19

Описание слайда:

In favour of laziness Laziness is jolly convenient

Слайд 20

Описание слайда:

Combinator libraries Recursive values are jolly useful

Слайд 21

Описание слайда:

Слайд 22

Описание слайда:

Laziness keeps you honest Every call-by-value language has given into the siren call of side effects But in Haskell (print “yes”) + (print “no”) just does not make sense. Even worse is [print “yes”, print “no”] So effects (I/O, references, exceptions) are just not an option. Result: prolonged embarrassment. Stream-based I/O, continuation I/O... but NO DEALS WIH THE DEVIL

Слайд 23

Описание слайда:

Monadic I/O A value of type (IO t) is an “action” that, when performed, may do some input/output before delivering a result of type t.

Слайд 24

Описание слайда:

Performing I/O A program is a single I/O action Running the program performs the action Can’t do I/O from pure code. Result: clean separation of pure code from imperative code

Слайд 25

Описание слайда:

Connecting I/O operations

Слайд 26

Описание слайда:

The do-notation Syntactic sugar only Easy translation into (>>=), return Deliberately imperative “look and feel”

Слайд 27

Описание слайда:

Control structures

Слайд 28

Описание слайда:

Generalising the idea

Слайд 29

Описание слайда:

Monads

Слайд 30

Описание слайда:

Example: a type checker

Слайд 31

Описание слайда:

The IO monad

Слайд 32

Описание слайда:

What have we achieved?

Слайд 33

Описание слайда:

What have we achieved?

Слайд 34

Описание слайда:

What we have not achieved

Слайд 35

Описание слайда:

Open challenge 1

Слайд 36

Описание слайда:

Open challenge 2

Слайд 37

Описание слайда:

Monad summary Monads are a beautiful example of a theory-into-practice (more the thought pattern than actual theorems) Hidden effects are like hire-purchase: pay nothing now, but it catches up with you in the end Enforced purity is like paying up front: painful on Day 1, but usually worth it But we made one big mistake...

Слайд 38

Описание слайда:

Our biggest mistake Using the scary term “monad” rather than “warm fuzzy thing”

Слайд 39

Описание слайда:

What really matters? Laziness Purity and monads Type classes Sexy types

Слайд 40

Описание слайда:

SLPJ conclusions Purity is more important than, and quite independent of, laziness The next ML will be pure, with effects only via monads. The next Haskell will be strict, but still pure. Still unclear exactly how to add laziness to a strict language. For example, do we want a type distinction between (say) a lazy Int and a strict Int?

Слайд 41

Описание слайда:

Слайд 42

Описание слайда:

Type classes Initially, just a neat way to get systematic overloading of (==), read, show.

Слайд 43

Описание слайда:

Implementing type classes

Слайд 44

Описание слайда:

Type classes over time Type classes are the most unusual feature of Haskell’s type system

Слайд 45

Описание слайда:

Type classes are useful Type classes have proved extraordinarily convenient in practice Equality, ordering, serialisation, numerical operations, and not just the built-in ones (e.g. pretty-printing, time-varying values) Monadic operations

Слайд 46

Описание слайда:

Quickcheck ghci> quickCheck propRev OK: passed 100 tests ghci> quickCheck propRevApp OK: passed 100 tests Quickcheck (which is just a Haskell 98 library) Works out how many arguments Generates suitable test data Runs tests

Слайд 47

Описание слайда:

Quickcheck

Слайд 48

Описание слайда:

Extensiblity Like OOP, one can add new data types “later”. E.g. QuickCheck works for your new data types (provided you make them instances of Arby) ...but also not like OOP

Слайд 49

Описание слайда:

Type-based dispatch A bit like OOP, except that method suite passed separately? double :: Num a => a -> a double x = x+x No: type classes implement type-based dispatch, not value-based dispatch

Слайд 50

Описание слайда:

Type-based dispatch double :: Num a => a -> a double x = 2*x means double :: Num a -> a -> a double d x = mul d (fromInteger d 2) x The overloaded value is returned by fromInteger, not passed to it. It is the dictionary (and type) that are passed as argument to fromInteger

Слайд 51

Описание слайда:

Type-based dispatch So the links to intensional polymorphism are much closer than the links to OOP. The dictionary is like a proxy for the (interesting aspects of) the type argument of a polymorphic function. f :: forall a. a -> Int f t (x::t) = ...typecase t... f :: forall a. C a => a -> Int f x = ...(call method of C)...

Слайд 52

Описание слайда:

Cool generalisations Multi-parameter type classes Higher-kinded type variables (a.k.a. constructor classes) Overlapping instances Functional dependencies (Jones ESOP’00) Type classes as logic programs (Neubauer et al POPL’02)

Слайд 53

Описание слайда:

Qualified types Type classes are an example of qualified types [Jones thesis]. Main features types of form .Q =>  qualifiers Q are witnessed by run-time evidence Known examples type classes (evidence = tuple of methods) implicit parameters (evidence = value of implicit param) extensible records (evidence = offset of field in record) Another unifying idea: Constraint Handling Rules (Stucky/Sulzmann ICFP’02)

Слайд 54

Описание слайда:

Type classes summary

Слайд 55

Описание слайда:

Слайд 56

Описание слайда:

Sexy types Haskell has become a laboratory and playground for advanced type hackery Polymorphic recursion Higher kinded type variables data T k a = T a (k (T k a)) Polymorphic functions as constructor arguments data T = MkT (forall a. [a] -> [a]) Polymorphic functions as arbitrary function arguments (higher ranked types) f :: (forall a. [a]->[a]) -> ... Existential types data T = exists a. Show a => MkT a

Слайд 57

Описание слайда:

Is sexy good? Yes! Well typed programs don’t go wrong Less mundanely (but more allusively) sexy types let you think higher thoughts and still stay [almost] sane: deeply higher-order functions functors folds and unfolds monads and monad transformers arrows (now finding application in real-time reactive programming) short-cut deforestation bootstrapped data structures

Слайд 58

Описание слайда:

How sexy? Damas-Milner is on a cusp: Can infer most-general types without any type annotations at all But virtually any extension destroys this property Adding type quite modest type annotations lets us go a LOT further (as we have already seen) without losing inference for most of the program. Still missing from even the sexiest Haskell impls  at the type level Subtyping Impredicativity

Слайд 59

Описание слайда:

Destination = Fw

Слайд 60

Описание слайда:

Modules

Слайд 61

Описание слайда:

Modules

Слайд 62

Описание слайда:

Modules Haskell has many features that overlap with what ML-style modules offer: type classes first class universals and existentials Does Haskell need functors anyway? No: one seldom needs to instantiate the same functor at different arguments But Haskell lacks a way to distribute “open” libraries, where the client provides some base modules; need module signatures and type-safe linking (e.g. PLT,Knit?).  not ! Wanted: a design with better power, but good power/weight.