Hacker News Reader

The difference between parsing and validation in the author's formulation is not between returning Maybe and throwing an exception, it's between returning a more precise type and not. Here's the types of the two version of `getConfigurationDirectories`:

    getConfigurationDirectories :: IO [FilePath]
    getConfigurationDirectories :: IO (NonEmpty FilePath)

The second version is preferred because the (NonEmpty FilePath) encodes the property that was checked in the type which means it doesn't have to be handled repeatedly throughout the entire rest of the program.

Yes the second version could have been changed to one of:

    getConfigurationDirectories :: IO (Maybe (NonEmpty FilePath))
    getConfigurationDirectories :: MaybeT IO (NonEmpty FilePath)

but this would only have moved the error reporting up one level to the main function. I would guess the existing version was chosen to simplify the types for a non-Haskell audience.

your attempted 'improvement' of using

     getConfigurationDirectories :: IO (Maybe [FilePath])

is NOT an example of parsing because [FilePath] does not remove the possibility (in the types!) of the list being empty. When you later attempted to use

    maybeCache >>= useCache

this requires the type of useCache to have type

    [FilePath] -> IO a

for some output type a. This function must deal with the possibility of the input list being empty because the type allows it. Every call to `head` returns (Maybe FilePath) and must handle the Nothing case. 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. Presumably none of the lower-level functions will be able to provide a default FilePath to use so every single one will be forced to return a Maybe somewhere in their return type (or use fromJust which is very ugly). This affects every single one of their callees which will again be forced to propagate Maybe up to their callees etc. To reiterate: the issue is not the possible non-existence of Cache, which can be handled in main. It's that the representation of Cache forces every single operation on it (of which head is just one simple example) to potentially have to represent conditions that should not actually be possible. This is a failure to 'make invalid states unprepresentable', which most proponents of static types aspire to.

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.