4 Matching Annotations
  1. Aug 2020
    1. Commonly the above definition is called the identity function. But in fact we should think of it as a whole family of functions. We should really say that id is an identity function for all types a. In other words, for every type T you might come up with, there is an identity function called id, which is of type T -> T. This is the type-checker’s view anyway, and by turning on the RankNTypes extension we can be explicit about that in our code: {-# LANGUAGE RankNTypes #-} id :: forall a. a -> a id x = x

      This is such a nice description of forall. It should be combined with forall is the type-level "lambda" (also saved it here).

    2. Now it is much clearer that id is really a family of infinitely many functions. It is fair to say that it is an abstract function (as opposed to a concrete one), because its type abstracts over the type variable a. The common and proper mathematical wording is that the type is universally quantified (or often just quantified) over a.

      This was very neatly put, and forall above is also spot on.

    1. Quantified Types

      My main issue with this book is that the difficulty is exponentially increasing, and by "keeping it simple" (i.e., trying to use simple terms) it is even harder to do a proper research.

      For example:

      1. The name of this chapter

      This chapter should have been called Explicitly quantified type or Explicit universal quantification as it is too general as is, and doing a search to get to know more when someone has no formal/previous functional programming background, makes very hard.

      Most importantly though, even if Haskell not mentioned, the word "explicit" would have been important.

      It is also more about generic parameters than about quantification itself, and forall is kind of introduced but it is totally misleading.

      2. forall

      The post “forall” is the type-level “lambda” (saved) is the best, most succinct explanation of forall that I ever found. Unfortunately not before going down the rabbit hole.. (See links below.) One still needs to know about

      • typeclasses
      • generic parameters
      • constraints
      • what pragmas are but after that, it is straightforward.

      (Jordan's Reference section on forall also doesn't help much.)

      forall is also mandatory in PureScript (which is also not mentioned when introducing it), and I believe a comparison (the way the above post did) with Haskell is important, but at the right time. At least Jordan's Reference tries to put it off until later, but still before explaining concepts required to understand it.

      3. The "rabbit hole" links

      These are all good resources, but not for uninitiated mortals, and at a lower level (such as where I am now) they raise more questions than answers.