Hacker News Reader

This line:

    maybeCache <- (getCofDirs >>= head >> initializeCache)

is doing exactly what the post is arguing against. getConfDirs is validating the list is non-empty but the [FilePath] list it contains does not encode that information. Now you immediately have to handle the possibility of a missing value from head that you already know cannot happen. This isn't too apparent here since you've combined it into a single expression but if you need to pass the confDirs list to any other part of the program they will also have to continually handle the possibility of the list being empty even though you already checked for that possibility. Now every function that interects with the confDirs list will have to include (Maybe a) in its return type unnecessarily. The post is not suggesting you can remove Maybe entirely but it has moved it to a single point in the program (the point where the config dirs list is checked for emptiness) and removed it everywhere else. Your approach must continually guard against an impossible condition everywhere the dirs list is accessed because you discard the property you checked for in getConfDirs.

The monadic operators make it convenient to propagate missing values through a chain of operations but they are not the primary benefit of an explicit Maybe type. Much like IO, the benefit of having an explicit Maybe type is when you _don't_ have it since its absence represents more information at that point in the program. Likewise a (NonEmpty a) contains more informatation than [a] which consequently makes the implementation of head more informative.

The parsers in this approach have types like

    a -> Maybe b

where type b contains the extra information extracted by the parser. Your getConfDirs function only contains a function with type

    [a] -> Maybe [a]

so isn't parsing in the same way.

View on HN

> Neither I nor the author is unaware that there are many combinators that make this more convenient than explicit matching against Just/Nothing but doing so is strictly worse than returning a FilePath directly

> 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'

> 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.