为什么要在数据类型定义中对函数进行编码？

Question

I find it hard to get the intuition about encoding function in data type definition. This is done in the definition of the State and IO types, for eg

data State s a = State s -> (a,s)
type IO a = RealWorld -> (a, RealWorld) -- this is type synonym though, not new type

I would like to see a more trivial example to understand its value so I could possibly build on this to have more complex examples. For eg say I have a data structure, would that make any sense to encode a function in one of the data constructor.

data Tree = Node Int (Tree) (Tree) (? -> ?) | E

I am not sure what I am trying to do here, but what could be an example of a function that I can encode in such a type? And why would I have to encode it in the type, but not use it as a normal function, I don't know, maybe passed as argument when needed?

Answer 1

Really, functions are just data like anything else.

Prelude> :i (->)
data (->) ab -- Defined in `GHC.Prim'
instance Monad ((->) r) -- Defined in `GHC.Base'
instance Functor ((->) r) -- Defined in `GHC.Base'

This comes out very naturally and without anything conceptually surprising if you consider only functions from, say, Int . I'll give them a strange name: _{(remember that (->) ab means a->b )}

type Array = (->) Int

What ? Well, what's the most important operation on an array?

Prelude> :t (Data.Array.!)
(Data.Array.!) :: GHC.Arr.Ix i => GHC.Arr.Array ie -> i -> e
Prelude> :t (Data.Vector.!)
(Data.Vector.!) :: Data.Vector.Vector a -> Int -> a

Let's define something like that for our own array type:

(!) :: Array a -> Int -> a
(!) = ($)

Now we can do

test :: Array String
test 0 = "bla"
test 1 = "foo"

FnArray> test ! 0
"bla"
FnArray> test ! 1
"foo"
FnArray> test ! 2
"*** Exception: :8:5-34: Non-exhaustive patterns in function test

Compare this to

Prelude Data.Vector> let test = fromList ["bla", "foo"]
Prelude Data.Vector> test ! 0
"bla"
Prelude Data.Vector> test ! 1
"foo"
Prelude Data.Vector> test ! 2
"*** Exception: ./Data/Vector/Generic.hs:244 ((!)): index out of bounds (2,2)

Not all that different, right? It's Haskell's enforcement of referential transparency that guarantees us the return values of a function can actually be interpreted as inhabitant values of some container. This is one common way to look at the Functor instance: fmap transform f applies some transformation to the values "included" in f (as result values). This works by simply composing the transformation after the target function:

instance Functor (r ->) where
  fmap transform f x = transform $ f x

(though you'd of course better write this simply fmap = (.) .)

Now, what's a bit more confusing is that the (->) type constructor has one more type argument: the argument type . Let's focus on that by defining

{-# LANGUAGE TypeOperators #-}

newtype (:<-) a b = BackFunc (b->a)

To get some feel for it:

show' :: Show a  =>  String :<- a
show' = BackFunc show

ie it's really just function arrows written the other way around.

Is (:<-) Int some sort of container, similarly to how (->) Int resembles an array? Not quite. We can't define instance Functor (a :<-) . Yet, mathematically speaking, (a :<-) is a functor, but of a different kind: a contravariant functor .

instance Contravariant (a :<-) where
  contramap transform (BackFunc f) = BackFunc $ f . transform

"Ordinary" functors OTOH are covariant functors . The naming is rather easy to understand if you compare directly:

fmap      :: Functor f       => (a->b) -> f a->f b
contramap :: Contravariant f => (b->a) -> f a->f b

While contravariant functors aren't nearly as commonly used as covariant ones, you can use them in much the same way when reasoning about data flow etc.. When using functions in data fields, it's really covariant vs. contravariant you should foremostly think about, not functions vs. values – because really, there is nothing special about functions compared to "static values" in a purely functional language.

---

About your Tree type

I don't think this data type could be made something really useful, but we can do something stupid with a similar type that may illustrate the points I made above:

data Tree' = Node Int (Bool -> Tree) | E

That is, disconsidering performance, isomorphic to the usual

data Tree = Node Int Tree Tree | E

Why? Well, Bool -> Tree is similar to Array Tree , except we don't use Int s for indexing but Bool s. And there are only two evaluatable boolean values. Arrays with fixed size 2 are usually called tuples. And with Bool->Tree ≅ (Tree, Tree) we have Node Int (Bool->Tree) ≅ Node Int Tree Tree .

Admittedly this isn't all that interesting. With functions from a fixed domain the isomorphism are usually obvious. The interesting cases are polymorphic on the function domain and/or codomain, which always leads to somewhat abstract results such as the state monad. But even in those cases, you can remember that nothing really seperates functions from other data types in Haskell.

Answer 2

You generally start FP learning with 2 concepts - data types and functions . Once you have good confidence level of designing programs using these 2 concepts I would suggest you start using only 1 concept ie of types which means:

• You define new types by combining the existing types or type constructors in the language.
• You define new type constructors to abstract out a general concept in your problem domain.

• Function is a just a type which maps a particular type to another type. Which basically means that the types which the functions maps could themselves be functions and so on (because we just said that functions are type). This is what people generally call higher oreder functions and also this gives you the illusion that a function takes multiple parameters, whereas reality is that a function type always map a type to another type (ie it is a unary function), but we know that the another type can itself be a function type.

  Example : add :: Int -> Int -> Int is same as add :: Int -> (Int -> Int) . add is (function) type which maps an Integer to a (function) type which maps an Integer to an Integer.

• To create a Function type we use the (->) type constructor provided by Haskell.

Thinking in terms of above points you will find that the line between data types and functions is no more there.

As far as which type to choose is concerned, it solely depends on the problem domain you are trying to solve. Basically, when ever there is a need where you find that you need some sort of mapping from one type to another, you will use the (->) type.

The State is defined using function type because the way we represent state in FP is "a mapping which takes current state and returns a value and new state", as you can see that there is a mapping happening here and hence the use of (->) type.

Answer 3

Let's see if this helps. Unfortunately for beginners, the definition of State quotes State both on the left and right hand side, but they have different meaning: one is the name of the type, the other is the name of the constructor. So the definition is really:

        data State s a = St (s -> (a,s))

Which means you can construct a value of type State sa using constructor St and passing it a function from s to (a,s), that is, a function that can construct a value of some type a and a value of next state s from the previous state. This is a simple way to represent a state transition.

In order to see why passing a function is useful, you need to study how the rest of it works. For example, we can construct new value of type State sa given two other values by composing the functions. By composing such States, such state transition functions, you get a state machine, which then can be used to compute a value and final state, given an initial state.

        runStateMachine :: State s a -> s -> (a,s)
        runStateMachine (St f) x = f x   -- or shorter, runStateMachine (St f) = f -- just unwrap the function from the constructor