Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In my Haskell learning journey, I can't help but notice that parametricity is of the utmost importance in the language. Given how the type system and the inference capability of the compiler works, i think it is safe to say that parametricity or parametric polymorphism is natural, encourage and at the core of the philosophy of the language.
While the question I am going to ask is not specific to Haskell and could be ask to almost any programming language community, I'm quite intrigued at the point of view of the Haskellers, given the nature of the language as suggested above.
Why is parametricity so important to Haskellers? The language does really encourage to code to generic type and somewhat let the compiler figure out the right type when it is the most appropriate time (when it is forced too). Granted one does not have to stick to that, and we can and it is probably a good practice to declare the type.
But somehow I have the feeling, the all thing encourage you to be generic and not focus on the concrete type at first, adding the capability you need to the signature through type class, and focus on the composition and delay the concrete type at last, or leave it to the compiler.
I'm not completely sure of what I am saying but it feels that way.
I'm probably biased because I read a book in Scala, that also encourage that, although it is way more manual activity to than in Haskell.
Any philosophical response to that maybe? I have some idea about it, but from your point of you, how parametricity help programming faster and maybe safer too?
Note: I'm a Scala programmer learning Haskell
Edit
I illustrate my propos as I am studying with "Programming Haskell from first principles". To cite the author:
"There are some caveats to keep in mind here when it comes to using
concrete types. One of the nice things about parametricity and type
classes is that you are being explicit about what you mean to do with
your data, which means you are less likely to make a mistake. Int is a
big datatype with many inhabitants and many type classes and
operations defined for it—it would be easy to make a function that
does something unintended. Whereas if we were to write a function,
even if we have Int values in mind for it, that uses a polymorphic
type constrained by the type class instances we want, we could ensure
we only use the operations we intend. This isn’t a panacea, but
sometimes it can be worth avoiding concrete types for these (and
other) reasons.
(Page 208). "
I'd like to know what are the other reasons .... I mean this parametricity when compare to Scala that has it way more manual, is so baked in the language, I can't help think that is is part of the productivity philosophy of the language.
Parametricity is important because it restricts the implementation space. It's often the case that a properly parametric type restricts the implementation space down to a single implementation that lacks bottoms. Consider fst :: (a, b) -> a, for instance. With that type, there is only one possible return value from the function that doesn't have bottoms in it.
There are a lot of ways to write it that have bottoms - undefined, error, infinite loops, all of which varying in terms of eta expansion of the definition and whether the pair's constructor is matched. Many of these differences can be observed externally by careful means, but the thing they all have in common is that they don't produce a usable (non-bottom) value of type a.
This is a strong tool for implementing a definition. Given the guarantees parametricity makes, it's actually sufficient to test only that fst ((), ()) == (). If that expression evaluates to True, the implementation is correct. (Ok, it's not quite that simple in ghc, given the ability to break all sorts of rules with unsafe functions. You also need to validate that the implementation doesn't use anything unsafe that breaks parametricity.)
But guiding the implementation is only the first benefit. A consequence of the implementation being so limited is that parametricity also turns the type into concise, precise, and machine-checked documentation. You know that no matter what the implementation is, the only non-bottom value it can return is the first element of the pair.
And yes - usually things aren't quite so constrained as in the type of fst. But in every case where parametric polymorphism is present in a type, it restricts the implementation space. And every time the implementation space is restricted, that knowledge serves as machine-checked documentation of implementation of the type.
Parametricity is a clear win for both the implementor and user of code. It reduces the space for incorrect implementations and it improves precision and accuracy of documentation. This should be as close to an objectively good thing as there is in programming.
Related
I have been playing around with LiquidHaskell and Idris lately and i got a pretty specific question, that i could not find a definitive answer anywhere.
Idris is a dependently typed language which is great for the most part. However i read that some type terms during type checking can "leak" from compile-time to run-time, even tough Idris does its best to eliminate those terms (this is a special feature even..). However, this elimination is not perfect and sometimes it does happen. If, why and when this happens is not immediately clear from the code and sometimes has an effect on run-time performance.
I have seen people prefering Haskells' type system, because it cannot happen there. When type checking is done, it is done. Types are "thrown away" and not used during run-time.
What is the story for LiquidHaskell? It enhances the type system capabilities quite a bit over traditional Haskell. Does LiquidHaskell also inject run-time bits for certain type "constellations" or (as i suspect) just adds another layer of "better" types over Haskell that do not affect run-time in any shape or form.
Meaning, if one removes the special LiquidHaskell type annotations and compiles it with standard GHC, is the code produced always the same? In other words: Is the LiquidHaskell extension compile-time only?
If yes, this seems like the best of both worlds, or is LiquidHaskell just not as expressive in the type system as Idris and therefore manages without run-time terms?
To answer your question as asked: Liquid Haskell allows you to provide annotations that a separate tool from the compiler verifies. Code is still compiled exactly the same way.
However, I have quibbles with your question as asked. It can be argued that there are cases in which some residue of the type must survive at run time in Haskell - especially when polymorphic recursion is involved. Consider this function:
lots :: Show a => Int -> a -> String
lots 0 x = show x
lots n x = lots (n-1) (x,x)
There is no way to statically determine the exact type involved in the use of show. Something derived from the types must survive to runtime. In practice, this is easy to do by using type class dictionaries. The theoretically important detail is that there's still type-directed behavior being chosen at runtime.
I am learning Haskell and trying to understand the Monoid typeclass.
At the moment, I am reading the haskellbook and it says the following about the pattern (monoid):
One of the finer points of the Haskell community has been its
propensity for recognizing abstract patterns in code which have
well-defined, lawful representations in mathematics.
What does the author mean by abstract patterns?
Abstract in this sense is the opposite of concrete. This is probably one of the key things to understand about Haskell.
What is a concrete thing? Well, most values in Haskell are concrete. For example 'a' :: Char. The letter 'a' is a Char value, and it's a concrete value. Char is a concrete type. But in 1 :: Num a => a, the number 1 is actually a value of any type, so long as that type has the set of functions that the Num typeclass sets out as mandatory. This is an abstract value! We can have abstract values, abstract types, and therefore abstract functions. When the program is compiled, the Haskell compiler will pick a particular concrete value that supports all of our requirements.
Haskell, at its core, has a very simple, small but incredibly flexible language. It's very similar to an expression of maths, actually. This makes it very powerful. Why? because most things that would be built in language constructs in other languages are not directly built into Haskell, but defined in terms of this simple core.
One of the core pieces is the function, which, it turns out, most of computation is expressible in terms of. Because so much of Haskell is just defined in terms of this small simple core, it means we can extend it to almost anywhere we can imagine.
Typeclasses are probably the best example of this. Monoid, and Num are examples of typeclasses. These are constructs that allow programmers to use an abstraction like a function across a great many types but only having to define it once. Typeclasses let us use the same function names across a whole range of types if we can define those functions for those types. Why is that important or useful? Well, if we can recognise a pattern across, for example, all numbers, and we have a mechanism for talking about all numbers in the language itself, then we can write functions that work with all numbers at once. This is an abstract pattern. You'll notice some Haskellers are quite interested in a branch of mathematics called Category Theory. This branch is pretty much the mathematical definition of abstract patterns. Contrast this ability to encode such things with the inability of other languages, where in other languages the patterns the community notice are often far less rigorous and have to be manually written out, and without any respect for its mathematical nature. The beauty of following the mathematics is the extremely large body of stuff we get for free by aligning our language closer with mathematics.
This is a good explanation of these basics including typeclasses in a book that I helped author: http://www.happylearnhaskelltutorial.com/1/output_other_things.html
Because functions are written in a very general way (because Haskell puts hardly any limits on our ability to express things generally), we can write functions that use types which express such things as "any type, so long as it's a Monoid". These are called type constraints, as above.
Generally abstractions are very useful because we can, for example, write on single function to operate on an entire range of types which means we can often find functions that do exactly what we want on our types if we just make them instances of specific typeclasses. The Ord typeclass is a great example of this. Making a type we define ourselves an instance of Ord gives us a whole bunch of sorting and comparing functions for free.
This is, in my opinion, one of the most exciting parts about Haskell, because while most other languages also allow you to be very general, they mostly take an extreme dip in how expressive you can be with that generality, so therefore also are less powerful. (This is because they are less precise in what they talk about, because their types are less well "defined").
This is how we're able to reason about the "possible values" of a function, and it's not limited to Haskell. The more information we encode at the type level, the more toward the specificity end of the spectrum of expressivity we veer. For example, to take a classic case, the function const :: a -> b -> a. This function requires that a and b can be of absolutely any type at all, including the same type if we like. From that, because the second parameter can be a different type than the first, we can work out that it really only has one possible functionality. It can't return an Int, unless we give it an Int as its first value, because that's not any type, right? So therefore we know the only value it can return is the first value! The functionality is defined right there in the type! If that's not mindblowing, then I don't know what is. :)
As we move to dependent types (that is, a type system where types are first class, which means also that ordinary values can be encoded in the type system), we can get closer and closer to having the type system specify specifically what the constraints of possible functionality are. However, the kicker is, it doesn't necessarily speak about the implementation of the functionality unless we want it to, because we're in control of how abstract it is, but while maintaining expressivity and much precision. That's pretty fascinating, and amazingly powerful.
Much math can be expressed in the language that underpins Haskell, the lambda calculus.
In the Haskell community, we are slowly adding features of dependent types. Dependent types is an advanced typing feature by which types can depend on values. Some languages like Agda and Idris already have them. It appears to be a very advanced feature requiring an advanced type system, until you realize that python has had dependent types has had the dynamic typing version of dependent types, which may or may not be actual dependent types, from the beginning.
For most any program in a functional programming language, there is a way to reperesent it as an untyped lambda calculus term, no matter how advanced the typing. That's because typing only eliminates programs, not enable new ones.
Strong Typing wins us safety. How classes of errors that happened at run time can no longer happen at run time. This safety is rather nice. Besides this safety though, what does strong typing give you?
Are there an additional benefits of a strong type system besides safety?
(Note that I'm not saying that strong typing is worthless. Safety is a huge benefit in and of itself. I'm just wondering if there are additional benefits.)
First, we need to talk a bit about the history of the simply typed lambda calculus.
There are two historical developments of the simply typed lambda calculus.
When Alonzo Church described the lambda calculus the types were baked in as part of the meaning / operational behavior of the terms.
When Haskell Curry described the lambda calculus the types were annotations put on the terms.
So we have the lambda calculus a la Church and the lambda calculus a la Curry. See https://en.wikipedia.org/wiki/Simply_typed_lambda_calculus#Intrinsic_vs._extrinsic_interpretations for more.
Ironically, the language Haskell, which is named after Curry is based on a lambda calculus a la Church!
What this means is the types aren't simply annotations that rule out bad programs for you. They can "do stuff" too. Such types don't erase without leaving residue.
This shows up in Haskell's notion of type classes, which are really why Haskell is a language a la Church.
In Haskell, when I make a function
sort :: Ord a => [a] -> [a]
We're passing an object or dictionary for Ord a as the first argument.
But you aren't forced to plumb that argument around yourself in the code, it is the job of the compiler to build that up and use it.
instance Ord Char
instance Ord Int
instance Ord a => Ord [a]
So if you go and use sort on a list of strings, which are themselves lists of chars, then this will build up the dictionary by passing the Ord Char instance through the instance for Ord a => Ord [a] to get Ord [Char], which is the same as Ord String, then you can sort a list of strings.
Calling sort above, is a lot less verbose than manually building a LexicographicComparator<List<Char>> by passing it an IComparator<Char> to its constructor and calling the function with an extra second argument, if I were to compare the complexity of calling such a sort function in Haskell to calling it in C# or Java.
This shows us that programming with types can be significantly less verbose, because mechanisms like implicits and typeclasses can infer a large part of the code for your program during type checking.
On a simpler basis, even the sizes of arguments can depend on types, unless you want to pay fairly massive costs for boxing everything in your language up so that it has a homogeneous representation.
This shows us that programming with types can be significantly more efficient, because it can use dedicated representations, rather than paying for boxed structures everywhere in your code. An int can't just be a machine integer, because it has to somehow look like everything else in the system. If you're willing to give up an order of magnitude or more worth of performance at runtime, then this may not matter to you.
Finally, once we have types "doing stuff" for us, it is often beneficial to consider the refactoring benefits that mere safety provides.
If I refactor the smaller set of code that remains, it'll rewrite all that type-class plumbing for me. It'll figure out the new ways it can rewrite the code to unbox more arguments. I'm not stuck elaborating all of this stuff by hand, I can leave these mundane tasks to the type-checker.
But even when I do change the types, I can move arguments around fairly willy-nilly, comfortable that the compiler will very likely catch my errors. Types give you "free theorems" which are like unit tests for whole classes of such errors.
On the other hand, once I lock down an API in a language like Python I'm deathly afraid of changing it, because it'll silently break at runtime for all my downstream dependencies! This leads to baroque APIs that lean heavily on easily bit-rotted keyword-arguments, and the API of something that evolves over time rarely resembles what you'd build out of the box if you had it to do over again. Consequently, even the mere safety concern has long-term impact in API design once you ever want people to build on top of your work, rather than simply replace it when it gets too unwieldy.
That's because typing only eliminates programs, not enable new ones.
This is not a correct statement. Type-classes make it possible to generate parts of your program from type-level information.
Consider two expressions:
readMaybe "15" :: Maybe Integer
readMaybe "15" :: Maybe Bool
Here I'm using the readMaybe function from the Text.Read module. At term level those expressions are identical, only their type annotations are different. However, the results they produce at runtime differ (Just 15 in the first case, Nothing in the second case).
This is because the compiler generates code for you from the static type information you have. To be more precise, it selects a suitable type class instance and passes its dictionary to the polymorphic function (readMaybe in our case).
This example is simple, but there are way more complex use cases. Using the mtl library you can write computations that run in different computational contexts (aka Monads). The compiler will automatically insert a lot of code that manages the computational contexts. In a dynamically typed language, you would have no static information to make this possible.
As you can see, static typing not only cuts off incorrect programs but also writes correct ones for you.
You need "safety" when you already know what and how you want to write. It's a very small part of what types are useful for. The most important thing about types is that they make your reasoning structured. When someone writes in Python a + b he doesn't see a and b as some abstract variables — he sees them as some numbers. Types are already there in the internal language of humans, Python just doesn't have a type system to talk about them. The actual question in the "typed vs untyped (unityped) programming" dispute is "do we want to reflect our internal structured concepts in a safe and explicit or unsafe and implicit way?". Types don't introduce new concepts — it's untyped reasoning forgets the existing ones.
When someone looks at a tree (I mean a real green one) he doesn't see every single leaf on it, but he doesn't treat it as an abstract nameless object as well. "A tree" — is an approximation that is good enough for most cases and that's why we have Hindley-Milner type systems, but sometimes you want to talk about a specific tree and you do want to look at leaves. And that's what dependent types give you: the ability to zoom. "A tree without leaves", "a tree in the forest", "a tree of a particular form"... Dependently typed programming is just another step towards how humans think.
On a less abstract note, I have a type checker for a toy dependently typed language, where all typing rules are expressed as constructors of a data type. You don't need to dive into the type checking procedure to understand the rules of the system. That's the power of "zooming": you can introduce as complex invariants as you want, thus distinguishing essential parts from not important ones.
Another example of the power dependent types give you is various forms of reflection. Look e.g. at the Pierre-Évariste Dagand thesis, which proves that
generic programming is just programming
And of course types are hints, many functions and abstractions I defined I would define in a far more clumsy way in a weakly typed language, but types suggested better alternatives.
There is just no question "What to choose: simple types or dependent types?". Dependent types are always better and they of course subsume simple types. The question is "What to choose: no types or dependent types?", but that question doesn't stand for me.
Refactoring. By having a strong type system you can safely refactor code and have the compiler tell you whether what you are doing now even makes sense. The stronger the typing system, the more refactor errors are avoided. This of course means your code is a lot more maintainable.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Despite some experience with Lisp and ML, I'm having a great deal of trouble learning to read and (idiomatically) write Haskell because the local style seems to be
do eta elimination whenever possible
eschew parentheses in favor of exploiting operator precedence
pack half your logic into bucketloads of overloaded, non-alphanumeric infix operators
The last one is particularly difficult because there are so many predefined operators, each with their own conventions and general semantics, that often reading Haskell becomes an exercise in Hoogle and :type.
Are there any good tutorials that assume knowledge of CS/functional concepts, and instead focus on Haskell-specific idioms? I'm looking for something like Real-World Haskell, that starts off with a very naive, explicit program and then gradually transforms it into a more idiomatic style, introducing and explaining the idioms as it goes. But instead of introducing and explaining general concepts like monads and type classes, it would introduce specific monads and specific type classes, like "but this is exactly what the Alternative monoid does!"
Basic type classes like Show, Eq and Ord should be easy to grasp by reading the library documentation found by Hoogle and/or Haskell-2010 Language Report.
The numeric tower in Haskell seems to be convoluted (Int type is an instance of whooping 11 type classes according to the report), but it is just to support all useful kinds of numbers and number representations mathematicians invented for us: e.g. Integer is a arbitrary size integer, Int is usual machine word-sized integer, and a lazy Peano representation of integers (not in standard library) proved useful in implementation of graph algorithms. The most important numeric type classes are Num and Integral. You can convert between different integer types by using fromIntegral functions. Note also that numerals such as 123 have type Num a => a and there's special type defaulting mechanism designed to reduce the need of type declarations to specify exact numeric type you need. In advanced use cases this works against you so you may want to alter the defaults.
The same situation is with different types of strings: no single representation fits all, so many of them are in the wild: String, Data.ByteString and Data.Text are most important.
Regarding more complicated type classes the best source is Typeclassopedia.
For certain type classes such as Monad, Applicative and Arrow there are a lot of dedicated tutorials and research works. Depending on your math skills, you may also want to read original research papers on the category theory concepts behind the type classes such as excellent "Notions of computation and monads" by Eugenio Moggi.
As for "eta reductions" it is called Point-Free Style. You can get some information from
the references mentioned at that link. You can also look at Combinatory Logic, a 1978 paper by John Backus Can programming be liberated from von neumann style? and APL programming language to get a richer historical perspective on the point-free style.
Also there are general books on Haskell such as 'A Gentle Introduction to Haskell' and 'Learn You a Haskell for Great Good'.
As for operator precedence - there are really few operators you must remember: (.), ($) and (>>=) are used much more than everything else (barring arithmetics of course but arithmetic operators are rather unsurprising).
The syntax for tuples and lists seems unproblematic for me too. It is just redundant: foo : bar : [] is the same as [foo, bar] and (,) foo bar is the same as (foo, bar). The prefix versions of tuples of higher arity such as (,,,,) are rarely used.
See also http://www.haskell.org/haskellwiki/Section_of_an_infix_operator for explanation of constructs such as (+ 2) and (2 +) called sections.
Also you can learn from the changes the HLint tool suggests to improve your code. The HLint executable can be installed by cabal install HLint.
As for advanced topics, I can recommend studying purely functional data structures (lets you design efficient immutable data structures and reason about time consumption), call by need lambda calculus (lets you reason about what is evaluated and in which order), System Fc type system (gives you some background on how haskell type checker works), denotational semantic (reasoning about non-termination, partiality and recursion, and also some insight on the notions of strictness, purity and composability).
I think the "Write Yourself a Scheme in 48 Hours" tutorial is exactly what you're looking for. This tutorial explains how to implement a Scheme interpreter in Haskell; it's the one document that really made everything click for me.
It has concrete examples of various Haskell idioms and ideas all rolled together in a cool project. This is particularly good for somebody with experience in Lisp, especially if you've read something like SICP or have implemented a Scheme interpreter before. The tutorial is great either way, but it might be a little bit easier to follow if you've done something similar before.
Ive come across some answers (here in SO) saying that Haskell has many "dark corners" in its type system, and also some messy holes. Could someone elaborate on this?
Thanks in advance
I guess I should answer this, especially since two people so far have misinterpreted my remarks...
Regarding non-termination, the remark in question was slight hyperbole for dramatic effect, and referred to non-termination at the value level. This was in context of comparing Haskell to theorem provers, in an answer to someone who mentioned type-enforced correctness properties as something they particularly appreciated. In that sense, the presence of ⊥ inhabiting otherwise empty types is a "flaw", because it changes the meaning of a type like A -> B from "given an A, produces a B" into "given an A, either produces a B or crashes the program" which is, for obvious reasons, somewhat less satisfying from a proof-of-correctness standpoint.
It's also completely irrelevant to almost all day-to-day programming and no worse than any other general-purpose language because, of course, the possibility of non-termination is required for Turing-completeness.
I don't have any problem with UndecidableInstances. Actually, it bothers me less than ⊥ at the value level does because it only crashes GHC when compiling, not the finished program. OverlappingInstances is another matter, though, and the ad hoc mishmash of GHC extensions to provide little bits of things that would most naturally require dependent types certainly qualifies as "messy".
But keep in mind that most of the things I'm complaining about in Haskell are only a problem because of the otherwise very solid foundation. Most type systems in other statically typed languages aren't even coherent enough to be called "wrong" in comparison, and cleaning up the stuff I'm calling "messy" is an active and ongoing area of research.
Haskell's type system has no problems or messy holes, actually. Haskell 98 can be fully type-inferred. It possesses what is known as the "principal type" property, which is to say that any given expression has at most a single most general type. There are, however, a range of expressions which are good and useful and valid but do not type under Haskell 98. Most important of these are higher-ranked types. forall a b. (a -> b) -> a -> b is an (uninteresting) example of a rank-one type, which is to say that the forall is only at the very outside. forall b. -> (forall a. a -> a) -> b -> b is an example of a useless but possible type which is not rank-one, and cannot be expressed in Haskell98. Higher ranked types are one of many things which break the principal type property.
As one adds more and more extensions to the basic Haskell98 system, there begin to be tradeoffs introduced between the ability to write really powerful types which express both different types of polymorphism and different types of constraints and the ability to have as much code as possible completely type-inferred. At the very edges of what's possible, types can get messy and complicated, and occasionally you can run into things that seem like they should work but don't. But at that point, you're generally doing what's known as "type-level programming" where a great deal of your application logic has been embedded in the types themselves, and through a combination of typeclass tricks you've conned the compiler into, essentially, running the types as a program at compile time.
I disagree, by the way, with camccann's assertion that potential nontermination is a messy compromise in the type-checker. I think it's a perfectly useful feature, in fact a prerequisite for turning-completeness at the type level, and you only risk it if you explicitly ask the compiler to start allowing lots of dodgy stuff.
So you're referring to Camccann saying "Haskell's type system is full of holes, due to nontermination and other messy compromises"? I think he's talking about the UndecidableInstances extension and probably a few others.
Then you referred to Norman, I can only assume, saying "Haskell's type system is ambitious and powerful, but it is continually being improved, which means there is some inconsistency as a result of history.". I'm sure he had something in mind but will let him clarify when he see`s this question.