Hacker News Reader

    > I'm saying you would always prefer to be handed an instance of an `a` instead of a (Maybe a) since it's more precise.

I disagree with this. `Maybe a` is more precise because it more closely represents the actual system within which we are working. It is simply a fact that our configuration directories might not exist. It is only within the author's own head that they prefer a concrete type because they value being able to point to their variable and say, "look I have this value! It's right here!" in a procedural sense, more than adopting a more functional approach.

    > You can trivially construct a (Maybe a) from an a but you can't easily go in the other direction. You either need to produce a dfeault value or use a partial function like fromJust to obtain an 'a' from a 'Maybe a'

Again, the above is just not accurate! Or it is accurate in a very specific - "I want this particular value in this particular scope" - kind of way. Even in your example, we can be statically certain that `restOfProgram` will receive a value of type `[FilePath]`[0].

This is starting to feel like a waste of time. You are very much hung up on trying to defend the idea that using `Maybe` is something to be avoided. I understand where you are coming from. I really do. But you are simply not going to convince me because I prefer to model systems as a whole and I prefer to avoid doing extra gymnastics to solve already-solved problems. Throwing an exception? C'mon... we both know that example sucks.

My critique of the post really has nothing to do with choosing `Maybe` vs validating. My critique is that the author's code is utterly failing to exemplify parsing over validation! Using `Maybe` to chain parsers together in order to build an input would have been perfect. Unfortunately, they kind of mucked it up halfway through because they appear to be afraid of `Maybe`. It's a shame given that the post seems to have gotten around.

[0] This whole `NonEmpty` non-sense is a sideshow that's not worth discussing (other than to further illustrate how `Maybe` can be used to simplify multi-step parsing). What happens when you need the Nth element? You just keep re-defining the type to include more values? When we get to `NonEmpty6` I think maybe we will have realized we are on the wrong path. For our purposes it's better to think of `[FilePath]` as `Input` and not get bogged down in the specifics of its shape. The important bit is that it might not exist.

View on HN

> In your post the argument to restOfProgram has type [FilePath] but in the post it is (NonEmpty FilePath) so you need to handle the potential non-emptiness of the list everywhere you try to access it

// returns a non-empty list of string getConfigurationDirectories: () => [string, ...string[]] = () => { const dirs = getEnv("dirs").split(","); if (dirs.length < 1) throw "ERROR"; return dirs; }

// 1. This is their first example class ConfigurationDirectories { dirs: FilePath[]; constructor(env) { let dirs = env("config").split(","); if (dirs.length < 1) throw "Error!"; this.dirs = dirs; } get cacheDir() { if (this.dirs.length < 1) throw "Cannot happen!"; return this.dirs[0]; } } // 2. This is their "fixed" example with all sorts of unnecessary "NonEmpty" gymnastics because they have chosen the wrong abstraction type NonEmpty<T> = [T, ...T[]]; const eg: NonEmpty<string> = []; // error class ConfigurationDirectories { dirs: NonEmpty<FilePath>; constructor(env) { let dirs = env("config").split(","); if (dirs.length < 1) throw "Error!"; this.dirs = dirs as NonEmpty<FilePath>; } get cacheDir() { // now the compiler also knows dirs is not empty return this.dirs[0]; } } // 3. This is BETTER than their "fixed" example because it is even simpler class ConfigurationDirectories { cacheDir: FilePath; constructor(env) { let dirs = env("config").split(","); if (dirs.length < 1) throw "Error!"; this.cacheDir = dirs[0]; } } // usage const config = new ConfigurationDirectories(getEnv()); const cache = initializeCache(config.cacheDir);

The difference lies entirely in the return type: validateNonEmpty always returns (), the type that contains no information, but parseNonEmpty returns NonEmpty a, a refinement of the input type that preserves the knowledge gained in the type system.