Implement with types, not your brain (2019)

> just because the types check out doesn't mean it's free from bugs

That's certainly true in the general case. In fact, the author gives a type-checked-but-wrong example of "we need an Int, so just return zero."

But in some specific cases, as the author writes, "One of those facts we can infer [from a type signature] is often the the only possible implementation." The article demonstrates that "possible" includes "also makes use of all the values available (or else the signature would be simpler)."

I think a version of this applies to static types as well. Even under normal circumstances, I've noticed at times my own thoughts getting lazy when refactoring statically-typed code. I don't "load" as much of the program into my brain as I would otherwise; I just change the part I want to change and then fairly thoughtlessly fix all the type errors. I don't think this is a good thing. The OP takes this to an absolute extreme.

Static types are there to document and to catch bugs early; they cannot be used as a complete verification that your code is correct, much less a generative tool for writing logic where "you're not entirely sure how" it works.

And thinking with types helps you to do that. Satisfying the type checker doesn't guarantee a program is functionally correct but it does reject a large number of obviously incorrect programs from being considered. And with holes it can guide use towards the likely correct program.

From TFA:

> I’m not going to say that blindly filling in type holes always works, but I’d say maybe 95% of the time?

It's a tool. If you don't know how to implement something a good first approximation is understanding it's shape and filling in the holes. I think this is the spirit of what the article is demonstrating.

Writing the program so that it's clear is the next step. The final example, `zoop` is renamed to `foldr` once we realize what we're working with. This is how I often work with Haskell in practice: I know the types and shapes of values I need to produce and I work with the compiler to write an expression that fits the type. Then I rewrite for clarity and intent.

Most Haskell code I read in the wild is borderline incomprehensible because of things like poor naming choices. Typically I can rewrite the code to be clearer, but it's a lot of effort.

I think Haskell would benefit from some style guidelines that emphasize that your code ought to be understandable by others. That would at least counteract the natural tendency to believe that terseness is a virtue or a goal.

You can write incomprehensible C too. It's just that most people have stopped doing that.

In the reusable abstraction space, what you're talking about just doesn't happen. There aren't bugs that need to be hunted down by careful inspection in these things because the methods described in the article are sufficient to catch them. They'll fail to type check or have obvious flaws of the sort -Wall catches.

In the business logic domain, there is a lot more room for errors that can't be caught by those approaches. But code in that domain also can't be written like this in the first place, so it's kind of a strange criticism to say "the code I can't write like this contains bugs that are hard to track down when I try to write it like this."

I can sense one additional objection coming: "If this isn't for business logic, what value is it? I write business programs."

To that, I would answer that most programs are stuffed full of redundant non-business logic, and you don't even realize how bad it is. It took roughly 30 years of c-like languages for people to be fully on-board with the idea that 3-clause for loops are error-prone boilerplate separate from the business logic and worth abstracting out.

If you use Haskell enough you'll realize a lot of your code in most languages is there to fiddle with implementation details instead of working over the actual problem space. A lot of Haskell code takes the form of super-generic abstraction plumbing bits that serve to isolate a common pattern and make sure the edge cases are covered.

Those bits of code are the ones usually called "impossible to understand", which are fully described by their types, and which can be implemented with this approach.

I am familiar with free monads/extensible effects, so I know the idioms at play in that 1-argument function. We're taking an extensible effect, "peeling" State off it (this is an idiom of EEs) and returning the rest of the effects within StateT. I can now this is a way to interop between the State effect in the effect stack & the StateT monad transformer. I don't give 2 shits about the implementation - I can use this to solve my problems just fine.

EDIT: HAHA - I just realized that this function is called "hoist" which is exactly the name I would've given it based on common Haskell idioms. I didn't even read the name - just the type. That's the essence of Haskell :)

The trick is to make sure that as soon as you've written this garbage, you go back, split things up into proper methods with descriptive names. Even things like introducing intermediate variables goes a really long way towards improving readability.

To me, this is a starting point, not the finish line.

That's fine because you can enter zen state and refactor it using compiler hints ;)

I suspect that people wanting to learn Haskell actually want to learn a statically typed functional programming language. And if you also want that language suitable to everyday problems, the kind of things you are dealing with at work, then Haskell is probably not the best one to start with.

I love how Scott Wlaschin presents statically typed functional programming languages as straightforward and pragmatic solutions to everyday problems:

https://www.youtube.com/watch?v=PLFl95c-IiU

https://pragprog.com/book/swdddf/domain-modeling-made-functi...

Once you're comfortable with that (and the way it is presented here really isn't very complex) then Haskell becomes a lot easier to understand.

But Haskell is very distracting because it is much more expressive and complex than than ML dialects for example, so it will be a big learning curve before someone is comfortable reading someone else's Haskell code. For other statically typed functional programming languages (f.i. OCaml/ReasonML, F#, Elm) that is not the case.

Any time you see a '::', it means 'the thing on the left hand side has the type on the right hand side'. As such, you should parse this line as 'there is a function jonk that has a type '(a -> b) -> ((a -> Int) -> Int) -> ((b -> Int) -> Int)'.

A simple type in Haskell is `Int -> Bool`. This means a function that takes a value of type Int and return a value of type Bool.

Now `Int -> (Int -> Bool)`, means 'a function that takes a value of type Int and returns a function that takes a value of type Int and returns a value of type Bool'. And because currying, this can be also read as 'a function that takes a value of type Int, then a value of type Int, and returns a value of type Bool'. As in, if you first call the function with Int, you'll be getting an `Int -> Bool` in return. Then you call it again with Int, and then you get a Bool. Because of how we define precedence of things, this signature can also be written as `Int -> Int -> Bool`, which makes it a bit more readable. However, if you really want to grok Haskell you need to grok this equivalency early on.

Compare this to `(Int -> Int) -> Bool`. This means 'a function that takes a function that takes a type Int and returns a type Int, and returns a type Bool'. By this point you should see that the type is more readable than my human language descriptions.

One last thing you're missing is the types 'a' and 'b'. You'll notice that these start with a small letter, and that's because they are generic types. It means that in practice this function can be called with whatever type instead of 'a' and 'b' in the declaration, it's just that it must be the same type for all cases of 'a' and 'b'. For a simple example, let's look at a function that takes two Ints, a Bool, and returns the first Int if the boolean is true, otherwise the second. The type signature for this in Haskell would be `foo :: Int -> Int -> Bool -> Int`. However, the function doesn't really care that these are Ints - they might as well be any values. As such, we can define the function signature as `foo :: a -> a -> Bool -> a`. This is is naturally similar to generic in C++, Typescript or Rust.

Armed with this knowledge (albeit maybe explained a bit better - see Learn You A Haskell!) you should be able to read this complex type signature now.

  interface Adapter<S, T> {public T adapt(S s);}
  interface Statistic<T> {public int valueOf(T t);}
  interface Summary<T> {public int summarize(Statistic<T> st);}

  interface Jonk<A, B> {
    public Summary<B> jonk(Adapter<A, B> adapter, Summary<A> summary);
  }

  class MyJonk implements Jonk<A, B> {
    public Summary<B> jonk(Adapter<A, B> adapter, Summary<A> summary) {
      // Equivalent to the author's jonk ab aii = _
    }
  }

  class MyJonk implements Jonk<A, B> {
    public Summary<B> jonk(Adapter<A, B> adapter, Summary<A> summary) {
      return new Summary<B>() {
        public int summarize(Statistic<B> st) {
          // Equivalent to jonk ab aii = \bi -> _
        }
      }
    }
  }

  class MyJonk implements Jonk<A, B> {
    public Summary<B> jonk(Adapter<A, B> adapter, Summary<A> summary) {
    return new Summary<B>() {
      public int summarize(Statistic<B> st) {
        return summary.summarize( /* ...? */ );
          // Equivalent to jonk ab aii = \bi -> aii $ _
        }
      }
    }
  }

  // equivalent to jonk ab aii = \bi -> aii $ \a -> bi $ ab $ a
  class MyJonk implements Jonk<A, B> {
    public Summary<B> jonk(Adapter<A, B> adapter, Summary<A> summary) {
      return new Summary<B>() {
        public int summarize(Statistic<B> st) {
          return summary.summarize(new Statistic<A>() {
            public int valueOf(A a) {
              return st.valueOf(adapter.adapt(a));
            }
          });
        }
      }
    }
  }

http://learnyouahaskell.com/

I've deployed production code built with the exactly techniques in the article. it's doable and in my experience easy (modulo the large learning curve - pay it once, pay it forever)

The (very simple all things considered!) top-level type signature of `Sem (State s ': r) a -> S.StateT s (Sem r) a` is also something I've used in production (different library of the same sort)

All this means is that, with a robust enough type system, determining the correct type is exactly as complex as determining the correct implementation.

In some cases, in some languages, expressing the solution in the language of types may be more intuitive than and help guide the language of implementation, but, because they are essentially encoding each other, that's not only as subjective as any question of what is intuitive must be, but also an artifact of the particular type language and implementation language. In a different implementation language, the problem may be as (or more!) intuitive as it is in the type language in use.

That's how you discover what abstract logic you need. And then you implement that logic types first, because it's abstract, so the types are both enough to describe the functionality and much easier to reason about. And you go and refactor your old code by following the types (or the type errors, if you are more in the let the computer do the work mood).

But I have no idea how to do that in dynamically typed languages. AFAIK, they hinder refactoring as much as they can.

Even there, it's not true, right? It's been a while since I learned / used Haskell, but I think something that transforms a { name: 'bob' } to a { name: 'sally' } would fit that bill, right? So, there are many implementations which meet the type signature, but you'd be pretty surprised if your `identity` function did this.

This completely misses the point of the article...

The author demonstrates a general concept (type holes) on a simple piece of code, to explain and motivate how he used it the exact same methodology on a much more complex piece of code, `hoistStateIntoStateT`.

By the way, this is literally the most common foldr implementation in functional languages, so I have no idea why you would want to do a code review of it, or talk about performances in such a trivial setting, or pretend that you're confused by it so much that you have to refer to a library...

That's because the author didn't put a type hole before declaring arguments.

  zoop :: (a -> b -> b) -> b -> [a] -> b 
  zoop = _
  <interactive>:10:8: error:
    • Found hole: _ :: (a -> b -> b) -> b -> [a] -> b
      Where: ‘a’, ‘b’ are rigid type variables bound by
               the type signature for:
                 zoop :: forall a b. (a -> b -> b) -> b -> [a] -> b
               at <interactive>:9:1-38
    • In the expression: _
      In an equation for ‘zoop’: zoop = _
    • Relevant bindings include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
      Valid hole fits include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
        foldr :: forall (t :: * -> *) a b.
                 Foldable t =>
                 (a -> b -> b) -> b -> t a -> b
          with foldr @[] @a @b
          (imported from ‘Prelude’
           (and originally defined in ‘Data.Foldable’))

In a more general sense, by utilizing nominal types and defensive programming, you can get a lot of mileage by making there one obvious way to do something. A canonical example being a validation function that takes User and returns ValidUser. If theres only a single function in your codebase that can do that transformation, you can actually use a (debatably simpler) principle of following the types to guide implementation, and in fact, actively prevent the wrong implementation from being written in the first place.

These things are certainly possible to varying degrees with dynamically typed languages, or statically typed OOP languages, but Ive never encountered a paradigm that makes representing invalid program states impossible to the degree that statically typed FP makes possible.

    zoop _   b []       = b
    zoop abb b (a : as) = abb a $ zoop abb b as

    reduceRight _  acc [] = acc
    reduceRight fn acc (head : tail) =
        fn head $ reduceRight fn acc tail

The name doesn't mean nothing. Either you're a Haskeller not familiar with monad transformer idioms, or you're not a Haskeller just shouting your uninformed opinion.

Hoist means something very specific in the monad transformer world, and it really helps explain what this does. And the "StateToStateT" also is pretty literal (and in the types.)

I'd actually argue this name is boring & completely derived from the types.

But the ethos of the language is not "doing things the right way", it's "do it first, make it right while it grows". The biggest point of the language is on refactoring.

    zoop :: (a -> b -> b) -> b -> [a] -> b
    zoop _   b []       = b
    zoop abb b (a : as) = abb a $ zoop abb b as

You will probably run into this in Haskell more than other languages though, because you can write a lot of general and abstract code in Haskell. In most other languages you cannot abstract over the types (higher-kinded types needed), and many still even lack polymorphism.

This method is real. You can't literally write all your Haskell this way, but I turn my brain off and play type tetris as a nontrivial part of my workflow pretty often. I rarely _only_ do that, but it's nice to not have to exert conscious mental energy and instead use tetris-like muscle/visual memory to make progress towards a goal.