Haskell：类型签名完全是什么意思？

Question

I have the following code, which outlines a language of boolean and arithmetic expressions:

data Exp a where
 Plus :: Exp Int -> Exp Int -> Exp Int
 Const :: (Show a) => a -> Exp a 
 Not :: Exp Bool -> Exp Bool
 And :: Exp Bool -> Exp Bool -> Exp Bool
 Greater :: Exp Int -> Exp Int -> Exp Bool

Below is code for a function that evaluates only arithmetic expressions:

evalA (Plus a b) = evalA a + evalA b
evalA (Const a) = a 

I am trying to figure out what type signature should be given to evalA such that it is total. However, I don't know what it means for for a type signature to be total. Any insights are appreciated.

Answer 1

The other answer explains that "total" is a property of functions, not type signatures; then goes on to say that if you want your function to be total, you must cover the other constructors of the GADT. But this is not the whole story.

The true story is that, for languages with advanced type systems like Haskell, "total" is a relation between functions and type signatures. So it is true that it is not a property of type signatures (it doesn't make sense to say, "this type signature is total"); but it is also not the case that it is a property of functions (it doesn't make sense to say, in isolation, "this function is total"! ¹ ).

So now, let's return to your question. You say:

data Exp a where
 Plus :: Exp Int -> Exp Int -> Exp Int
 Const :: (Show a) => a -> Exp a 
 Not :: Exp Bool -> Exp Bool
 And :: Exp Bool -> Exp Bool -> Exp Bool
 Greater :: Exp Int -> Exp Int -> Exp Bool

evalA (Plus a b) = evalA a + evalA b
evalA (Const a) = a 

Given our updated understanding, we can now ask a new and better, more precise question, which is: does there exist a type signature for evalA that, when paired with this implementation, causes the pairing to be total? The answer to this better question is yes , contrary to the claim in the other answer that says you must implement more cases of evalA . In particular, if we write

evalA :: Exp Int -> Int
evalA (Plus a b) = evalA a + evalA b
evalA (Const a) = a

then any well-typed application of evalA to a finite input will, in finite time, produce a non-bottom answer. (This is one sensible meaning of "total" for functions.)

Why may we ignore the Not , And , and Greater cases? Why, because we have demanded that the input have type Exp Int , and any well-typed term whose outer constructor is Not , And , or Greater will actually have type Exp Bool -- and so the application would not be well typed. So this can't crash with an inexhaustive pattern match error, as one might worry!

¹ One could say "this function, given any type signature which type-checks, is total". Indeed, it is common to say "this function is total" as a convenient shorthand to mean that. The other answer shows how to make your function total no matter what (correct) type signature is given.

Answer 2

A type signature can not be "total" or "non-total". At best, with such terminology someone could refer to types claiming that a result is always returned (except for non termination):

foo :: .. -> .. -> Result

in contrast to types wrapping the result in Maybe or something similar to denote that the result might not be there, after all:

foo :: .. -> .. -> Maybe Result

This would be a stretch of terminology, and I would not use it in that way.

Anyway, the Exp a type you mention is a GADT, which is a rather advanced feature of Haskell. It allows you to define

evalA :: Exp a -> a
evalA (Plus a b) = evalA a + evalA b
evalA (Const a) = a 
-- you should cover the other cases as well here

without requiring you to wrap the return type using Maybe or something similar, as it would happen with regular algebraic types.

---

Let's consider a simpler example: a language with integer and boolean literals, only.

data Exp where
  I :: Int -> Exp
  B :: Bool -> Exp

Now, it is impossible to define, say, semExpInt :: Exp -> Int without using some ugly trick:

semExpInt :: Exp -> Int
semExpInt (I i) = i                      -- OK!
semExpInt (B b) = error "not an Int!"    -- ugly!

In the latter case, we need to raise a runtime error, fail to terminate, or return an arbitrary integer. Essentially, we find a "runtime type error" inside Exp , which represents a value of the wrong type ( Bool instead of Int ).

If we try semExpBool :: Exp -> Bool we have a similar problem.

We could, and should, report the error using Maybe :

semExpInt :: Exp -> Maybe Int
semExpInt (I i) = Just i   -- OK
semExpInt (B b) = Nothing  -- OK, no result here

This is fine, but inconvenient. We are still reporting "runtime errors in the expression" in some way ( Nothing ). It would be better if we could avoid that, by taking as input an expression which we know would be of the right type. With GADTs we can write

data Exp t where
  I :: Int -> Exp Int
  B :: Bool -> Exp Bool

semExpInt :: Exp Int -> Int
semExpInt (I i) = i     -- no other cases to handle!

semExpBool :: Exp Bool -> Bool
semExpBool (B b) = b     -- no other cases to handle!

Or, even better, we can joint the two functions in a single one:

semExp :: Exp t -> t
semExp (I i) = i
semExp (B b) = b

Here, we claim that the result type is precisely the type t which is carried by the input type Exp t . So, this function will return an Int , or a Bool , depending on the input type.

this is even more convenient when adding operators to the expression. For instance,

data Exp where
  I :: Int -> Exp
  B :: Bool -> Exp
  And :: Exp -> Exp -> Exp

allows And (B True) (B False) , which is nice, but also allows And (I 2) (B False) which is nonsensical, since And should be used on booleans, only. This would have to be handled in the semantics:

semExpBool :: Exp -> Maybe Bool
semExpBool (I i) = Nothing
semExpBool (B b) = Just b
semExpBool (And e1 e2) = case (semExpBool e1, semExpBool e3) of
   (Just b1, Just b2) -> Just (b1 && b2)
   _                  -> Nothing          -- some arg was not a bool!

With GADTs, instead, we can express this:

data Exp t where
  I :: Int -> Exp Int
  B :: Bool -> Exp Bool
  And :: Exp Bool -> Exp Bool -> Exp Bool

Now, And (I 2) (B False) is disallowed since And requires a Exp Bool argument, and I 2 is not such.