Scala <> Haskell

An introduction and comparison of Scala and Haskell using examples.

Transcript

1. Scala <> Haskell Introducing and comparing both languages.
2. • The Basics
 • Type level programming
 • Libraries/Frameworks/ Community
3. The Basics 1. Two FP styles 2. Sum types 3. Pattern matching 4. Functions 5. Imperative constructions 6. Evaluation
4. 1. Two FP styles
5. Everything is an object
7. There are only functions and constants
9. 2. Sum/co-product types
10. A product type
11. A sum/co-product type
12. A sum/co-product type This approach introduces two new types: - True.type - False.type
13. A product type
14. A sum/co-product type
15. A sum/co-product type There is only one type: - Boolean and two constants: - True’ - False’
16. 3. Pattern matching
19. Product/Sum types are dual of pattern matching, the first constructs data, the second de- constructs data.
20. 4. Functions
21. Lambdas
24. Functions
27. Curried functions
28. The type of a function A => B
29. The type of a function A => B B = C => D
30. The type of a curried function A => C => D
31. A curried function
32. A curried function (named syntax)
33. The type of a function a -> b
34. The type of a function a -> b b = c -> d
35. The type of a curried function a -> c -> d
36. A curried function
37. A curried function (named syntax)
38. Multi-argument functions
39. Functions only accept one argument and return one result. Let’s see how can we emulate functions that receive more than one argument.
40. The type of a multi-arg function (A,B,…) => D
42. Shorter syntax
43. Even shorter syntax
44. The type of a multi-arg function (a,b,…) -> d
46. Even shorter syntax
47. Thanks to pattern matching we can syntactically emulate multi- argument functions
48. Curried functions are more common in Haskell, while multi-argument functions are more common in Scala
49. Curried functions allow partial function application
53. 5. Imperative constructions
54. Unrestricted side-effects
55. Side-effects only inside IO type
56. 6. Evaluation
57. Strict evaluation by default with lazy evaluation as an option
58. Strict
59. Lazy
60. Lazy evaluation by default with strict evaluation as an option
61. Lazy (non-strict semantics)
62. Strict
63. Evaluation-related keywords particular to Scala
64. Strict evaluation
65. Lazy evaluation
66. Haskell’s lazy-evaluation
67. Non-strict evaluation
68. Type-level programming 1. Type inference 2. Kind inference 3. Type classes 4. Multi-param type classes 5. Monad transformers
69. 1. Type inference
70. Local: variables and function return types
75. Global: almost all types are calculated
79. Type Inference Less polymorphic More permissive Haskell Scala Hindley-Milner
80. Things that make Scala’s type system more powerful (hence less type inference): - sub typing polymorphism - type lambdas - … Recommended reading (the comments section): 
 http://pchiusano.blogspot.com.es/2011/05/making-most-of- scalas-extremely-limited.html
81. 2. Kind inference
86. 3. Type classes
87. The expression problem Operation\Data Data1 Data2 New data easy in OOP / difficult in FP Operation1 Operation2 Operation3 New operation easy in FP / hard in OOP
90. Adding a new operation
91. Adding a new data type
95. Adding a new operation
96. Adding a new data type
98. 4. Multi-param type classes
100. How can we constraint the type parameters to allow more polymorphism?
101. The solution is to use functional dependencies (inspired by relational databases)
102. With functional dependencies
104. 5. Monad transformers
108. Type-level programming 1. Type inference 2. Kind inference 3. Type classes 4. Multi-param type classes 5. Monad transformers
109. Tooling Frameworks Libraries Conferences
110. akka, akka-http, spark, sbt, cats, scalaz, monocle, scalacheck, shapeless, JVM, …
111. scala world, lambda world, scalar, lambda conf, scala days, lx scala, typelevel submit, scala swarm, scala up north, scala exchange, scala io, compose, ICFP , …
112. mtl, lens, quickcheck, speculation, diagrams, criterion, darcs, xmonad, pandoc, yesod, …
113. zurihac, munihac, lambda conf, haskell symposium, lambda world, ICFP, BOB, compose, …
114. My view is that both languages are fantastic, Scala sacrifices type inference and some type safety in exchange of more power. Haskell tries to keep a core with good type inference and type safety even if that incurs in a less powerful type system
115. If you like FP in Scala, give Haskell a try!
116. If you know Haskell, learn you some Scala!
117. Questions?
118. Thank You