Haskell类型表示另一种类型的子集

Question

I think that when given parameter(s) of the specified type, a function should never fail.

But take this seemingly innocuous code:

readInts :: String -> [Int]
readInts = map read . words

It has a type signature that is too general, in fact, it will fail for any string that is not composed by space separated integers, its type should then be:

readInts :: SpaceSeparatedIntegersString -> [Int]

When the program fails when you try to build a SpaceSeparatedIntegersString that does not respect the stated criteria.

• Is implementing a SpaceSeparatedIntegersString a sensible idea?

• If it is how can I implement such a type? (I ask just a general idea/tip/nudge in the right direction, not full code)

• Should I just accept that my function will fail when the String formatting is not correct (that is, my statement at the start of tis question is wrong)?

• Should I just use a guard clause in the function definition?

Answer 1

Your goal is noble, but requires very precise types. Dependent types, such the ones available in Agda, Coq, Idris, and other languages can achieve what you propose. Eg in Coq,

Definition SpaceSeparatedIntegersString: Type :=
   { s: string | spaceSeparatedIntegers s } .
Definition spaceSeparatedIntegers (s: String): Prop := ...

The catch is that, whoever wants to construct a SpaceSeparatedIntegersString value, must provide a formal proof of the relevant property. This is feasible, but requires some care, time and mathematical skills.

In Haskell, it is more common to move the type-guarantee to the output type. Instead of making the input type stronger, we can make the output type weaker:

readInts :: String -> Maybe [Int]

This is not as precise, but can be used without having to prove anything.

Alternatively, make SpaceSeparatedIntegersString be an opaque type by declaring it in a module without exporting its value constructors.

module Foo(SpaceSeparatedIntegersString(), ...)
data SpaceSeparatedIntegersString = S String        -- S is private

In this way, the users of the module will have to manipulate it only through functions exported by the module. With some care, one can craft a bunch of (exported) combinators which guarantee that values of type SpaceSeparatedIntegersString will never contain invalid strings. For instance,

combine :: SpaceSeparatedIntegersString 
        -> SpaceSeparatedIntegersString
        -> SpaceSeparatedIntegersString 
combine (S x) (S y) = S (x ++ " " ++ y)

This is not entirely straightforward -- if you want to allow general string manipulation, you will probably end up in returning Maybe ... in some cases.

Answer 2

You probably shouldn't implement SpaceSeparatedIntegerString . If you did an abstract data type would be the simplest thing to do. You should not accept that your function should fail, at least not in the "pattern match failure" sense. You should make a function that returns something like Maybe [Int] .

The reason you shouldn't implement SpaceSeparatedIntegerString is that likely just pushes the problem elsewhere. You probably are getting the String s from some input, so somewhere you need a function String -> SpaceSeparatedIntegerString and that could fail just as well. At some point you need to go from less structured to more structured data unless your only values are completely statically specified.

The point is going from less structured data to more structured data (or less typed data to more typed data) is virtually always going to be a partial operation. Indeed, parsing is the process of turning less structured data into more structured data. What you should do, though, in line with your principle, is as much as practical reify the recovered structure into the type system. So isValidUri :: String -> Bool is bad, as is makeUri :: String -> Maybe String , but makeUri :: String -> Maybe Uri where Uri is a type that can represent exactly the valid URIs is good.

Answer 3

No, this is not a sensible idea in this case. The approach suggested in Ian Henry's comment using Maybe is one of several reasonable ones. The reason your idea is not sensible in this context is that the entire purpose of a function like readInts is to process input from the user, a file, an HTTP request, etc., which may not be valid. The type system can't help you if you ask the user how many cars they want to buy and they respond with a picture of a kitten. Derek Elkins really explains this better. chi's dependently typed approach is great for some other situations, once the input has been fully validated.