In a previous article we saw type constructors for ADTs, and how they are not types themselves. These are Maybe
and Either
in Haskell again:
The previous declaration for Maybe
names a type constructor that transforms a given type a
into a new type Maybe a
, such as Maybe Integer
or Maybe Char
. We cannot ask the type of Maybe
by itself to the Haskell interpreter:
$ ghci
Prelude> :type Maybe
<interactive>:1:1: error:
• Data constructor not in scope: Maybe
• Perhaps you meant variable ‘maybe’ (imported from Prelude)
The error we get back from the interpreter says that a data constructor named Maybe
could not be found. That is because it’s a type constructor instead. But there is a different question we can ask the interpreter, we can ask for its kind:
Prelude> :kind Maybe
Maybe :: * -> *
Type kinds are “types of types” and partition different type constructors that share the same arity into sets, just like types are sets of values. The kind of regular types such as Integer
and Char
is just *
. The kind *
is the kind of all types that can have values, and there is not really much more to it1. The kind of the type constructor Maybe
, on the other hand, is * -> *
2 which means that it takes any type of kind *
and gives back another type of kind *
. Why does this matter? It means that we cannot create the types Maybe Maybe
or Maybe Either
, because the kinds do not match. Kinds are how the compiler can make sure the application of the type constructors make sense:
Prelude> :kind Maybe Maybe
<interactive>:1:7: error:
• Expecting one more argument to ‘Maybe’
Expected a type, but ‘Maybe’ has kind ‘* -> *’
Prelude> :kind Maybe Either
<interactive>:1:7: error:
• Expecting two more arguments to ‘Either’
Expected a type, but ‘Either’ has kind ‘* -> * -> *’
Just as it is possible to partially apply a function in Haskell, it is also possible to partially apply a type constructor:
Prelude> :kind Either
Either :: * -> * -> *
Prelude> :kind Either Integer
Either Integer :: * -> *
Prelude> :kind Either Integer Char
Either Integer Char :: *
This means that Maybe
and Either a
have the same kind and can be used in type signatures whenever a type constructor of kind * -> *
is needed.
The Idris programming language is a language where types are first-class entities and therefore have types themselves. We can ask the Idris interpreter the same questions we asked the Haskell one before:
$ idris
Idris> :type Maybe
Maybe : Type -> Type
Idris> :type Either
Either : Type -> Type -> Type
As we can see Idris says that Maybe
is just a regular function that takes values of type Type
and returns other values of type Type
(the first type is obviously different than the second one). Therefore type kinds are not needed in Idris, because it only needs to check the function arity:
Idris> :type Maybe Either
Type mismatch between
Type -> Type -> Type (Type of Either)
and
Type (Expected type)
In Idris, all values of type Type
can be used as types in the traditional sense. It adds complexity to the language but it allows for powerful type constructions where the type of some values can depend on other values, instead of depending simply on other types as in Haskell. For instance, we can write a function that takes an Integer
or a Double
depending on the value of other argument to the function:
WantDouble : Bool -> Type
WantDouble False = Integer
WantDouble True = Double
-- the argument `number` will have either `Integer` or `Double` type,
-- depending on the value of `b`
processNumber : (b : Bool) -> WantDouble b -> String
processNumber False number = show (number + 1)
processNumber True number = show (number / 3.78)
In statically-typed programming languages all values are logically partitioned into sets which denote their types. For instance, numbers such as 1, 2, 99, and 456 are of the Integer
type. Other numbers such as 3.14, 67.88, and 0.123 are of the Real
type. When a value belongs to a type it is also said that such value inhabits that type. When types are viewed as theorems, we can also say that the value is a witness or a proof of the type it inhabits.
Algebraic data types, or ADTs, are a way of declaring new types often found in functional programming languages. The following simple ADT declares a new type for boolean values (the code snippets in this article will be given in Haskell):
This declaration introduces a new type, denoted by Bool
, which has only two values: True
and False
(this is how the Bool
type is actually defined in Haskell). When reading ADT declarations it is important to remember that the newly introduced name to the left of the equals sign is in the namespace of types, whereas the newly introduced names to the right of the equals sign are in the namespace of values. One could similarly create a new type for the days of the week:
Both newly introduced types are also called enumerations because they are sets of simple, fixed values. They are also called sum types, because their values are either one or other of the alternatives separated by the pipe symbol (|
), i. e., they are the sum of the alternatives. But is also possible to define product types, such as the following:
They are called product types because their values are the Cartesian products of other values, such as Integer
× Integer
in this case. Also notice that, although we have introduced the new name Point
on both sides of the equals sign, those names do not refer to the same thing. The Point
to the left of the equals sign is naming a new type, whereas the Point
to the right of the equals sign is naming a value constructor (also known as data constructor). We could as well have defined Point
this way:
Value constructors are not values themselves, but are function-like objects that, given some input values, build new values of the newly-declared type. Given the above declaration, this is how we can now create new values that inhabit Point
:
origin = MkPoint 0 0
p1 = MkPoint 0 100
p2 = MkPoint 33 33
They are “function-like” because, although they are invoked like regular functions, they are implemented by the compiler itself and just act as containers, holding the values passed to them for future use. For instance, let’s see which type is reported for the value constructor above by the Haskell interpreter:
$ ghci
Prelude> data Point = MkPoint Integer Integer
Prelude> :type MkPoint
MkPoint :: Integer -> Integer -> Point
It is very convenient that, in a language with first-class functions, value constructors are also functions. It allows one to create a list of points from two lists of coordinates with the simple snippet:
-- zipWith takes a function and two lists, and apply the function
-- to the corresponding elements of the lists yielding a new list
-- as a result
points = zipWith MkPoint xCoords yCoords
-- this is the type of applying zipWith to MkPoint as reported
-- by Haskell, brackets denote a list
zipWith MkPoint :: [Integer] -> [Integer] -> [Point]
We have seen sum and product types but, more generally, ADTs can be sum types of product types:
This is actually why they are called algebraic in the first place. With regard to the type declared above, all the following values inhabit ProjectivePoint
:
Just like we have value constructors, which transform values into values of other types, we can also have type constructors which transforms types into other types. One example is the very popular Maybe
ADT:
In this declaration Maybe
by itself does not denote a type, but a type constructor. The variable a
in this declaration stands for any other type, such as Integer
, Char
or other ADTs such as Bool
or Point
. Maybe Integer
, on the other hand, denotes a type. Values of this type can be created by one of the data constructors Nothing
or Just x
, where x
is some integer value. We can write thus a function that returns the square root of a real number if it is not negative:
-- function type
maybeSqrt :: Double -> Maybe Double
-- function implementation
maybeSqrt x = if x < 0 then Nothing
else Just (sqrt x)
Other such type constructor is Either
, which is a sum type whose values can hold values of either two different types, but not both at the same time:
The declaration Either Integer Double
denotes a type whose values can hold either integer or real numbers:
someInteger :: Either Integer Double
someInteger = Left 42
someDouble :: Either Integer Double
someDouble = Right 3.1415
It is also possible to create types that reference themselves. This is how an ADT for a list of values could be declared:
This declaration means that values of type List a
are either an empty list, or a value of type a
followed by another value of type List a
. Such ADTs are called recursive. Examples of values of this type are:
noInts :: List Integer
noInts = Empty
aDouble :: List Double
aDouble = Element 1.0 Empty
aMaybe :: List (Maybe Integer)
aMaybe = Element (Just 9) Empty
aCoupleMaybes :: List (Maybe Integer)
aCoupleMaybes = Element Nothing aMaybe
So far we have seen different ways of creating ADTs, but how do we use them? We can look into the values inside an ADT by using pattern matching, which means pairing patterns together with code to be executed in case the respective pattern matches. For instance we can write a function that converts booleans to zeros and ones:
It is not necessary to list all the patterns if we want to treat just some of them differently. The following function will test if a weekday is in the weekend or not:
For matching against data constructors which hold values, we name the values which will become local variables in the function scope:
hasBiggerThan10 :: Maybe Integer -> Bool
hasBiggerThan10 Nothing = False
hasBiggerThan10 (Just x) = x > 10
squaredDistance :: Point -> Point -> Integer
squaredDistance (MkPoint x1 y1) (MkPoint x2 y2) =
(x2 - x1) ^ 2 + (y2 - y1) ^ 2
getXCoord :: ProjectivePoint -> Maybe Integer
getXCoord PointInInfinity = Nothing
getXCoord (RealPoint x _) = Just x -- no need to name an unused value
-- pattern matching can unwrap data constructors at arbitrary levels
getSecondIntegerOrZero :: List (Maybe Integer) -> Integer
getSecondIntegerOrZero (Element _ (Element (Just x) _)) = x
getSecondIntegerOrZero _ = 0
This was a short introduction to algebraic data types which should give a good overview of what they can do, but there is much more to be said about them. Some resources for further reading:
]]>Lua is a programming language that, in the best Scheme tradition, takes pride in its extreme simplicity. But it takes things even further in one aspect: There is just one data structure, the associative array, or map. As Lua was designed from the beginning to be an extension language that could be picked up easily by non-programmers, this makes sense. And Lua’s usage numbers show this strategy worked. Lua is widely used as a scripting language for computer games, for instance.
In Lua maps are called tables. Although having tables as the only data structure in the language seems very limiting at first, the language has several features to help using tables in several different contexts. This post will be about enumerations in Lua.
In languages such as C and Java, enumerations are written like this:
The enumeration values are stored as integral types. The integer values can be assigned manually for one or more values, the remaining ones will get successive integers. The values can be used as integers, such as for indexing arrays.
In Lua it is possible to use a similar syntax, based on one of the several table constructors:
Colors = {
BLUE = 1,
GREEN = 2,
RED = 3,
VIOLET = 4,
YELLOW = 5,
}
-- the above is equivalent to:
Colors = {
["BLUE"] = 1,
["GREEN"] = 2,
["RED"] = 3,
["VIOLET"] = 4,
["YELLOW"] = 5,
}
-- reading the integer back
local color = Colors.RED -- the same as Colors["RED"]
This already goes some way to making our enumeration, but it’s not very convenient because we need to assign integers to every key in the table. If that’s not good enough a different table constructor could be used but the keys would need to be written as strings explicitly:
Colors = {
"BLUE",
"GREEN",
"RED",
"VIOLET",
"YELLOW",
}
-- which is equivalent to:
Colors = {
[1] = "BLUE",
[2] = "GREEN",
[3] = "RED",
[4] = "VIOLET",
[5] = "YELLOW",
}
Now items are numbered automatically but the keys and values are inverted. In this case we would need a helper function to switch those for us:
-- assumes the tbl is an array, i.e., all the keys are
-- successive integers - otherwise #tbl will fail
function enum(tbl)
local length = #tbl
for i = 1, length do
local v = tbl[i]
tbl[v] = i
end
return tbl
end
When passing a literal table (or string) to a function in Lua the parentheses can be omitted which lets us create a handy DSL:
Colors = enum {
"BLUE",
"GREEN",
"RED",
"VIOLET",
"YELLOW",
}
-- finally, get our integer from the enum!
local color = Colors.RED
As a side note, strings in Lua are immutable and interned by the interpreter, which means that accessing tables by string keys is very fast. In the table implementation the pointer to the interned string will be used instead of a hash function for looking up the associated values. This is not as fast as accessing an enumeration value in C, but in the interpreted world, it’s still very fast.
]]>I have had an interest in Haskell for a long time. When I first encountered the language, resources such as Real World Haskell and Learn You a Haskell didn’t exist yet, so I tried to make do with the A “Gentle” Introduction to Haskell, which had me scratching my head a lot. At that time I even started writing a tool in Haskell to help my father run his business. But then other things came up and I was left with that superficial knowledge of Haskell that I always wanted to deepen but never got to.
A couple of months ago I stumbled on some praise online for a new Haskell book, which promised to teach everything from first principles. When I saw that the book included chapters on more recent topics such as Foldable
and Traversable
and on things I never properly got such as the Reader
monad and monad transformers, I decided to give it a try. I was not disappointed. One of the many a-ha moments I had reading the book was about those famous monad transformers.
I had an ingrained notion that I brought from other languages that Haskell data types were just either enumerations or data containers. For instance:
-- enumeration
data Bool = False | True
-- container
data BinTree a = Nil | Node a (BinTree a) (BinTree a)
Therefore I was puzzled when reading code examples given in the book that seemed to just be about pointless wrapping and unwrapping of data with a MaybeT
monad transformer. Then I realized that this wrapping and unwrapping was being done in order to have access to the Monad
instance of MaybeT
and use its instance functions against the wrapped data. In other words, types were being used not to hold other data, as in a collection, but to change the behaviour of that same data.
A small example should demonstrate why this is useful. Let’s start a module:
In this example, there are two text files with key-value pairs. The first one is a dictionary from Portuguese to English:
casa house
carro car
mala suitcase
mesa table
and the second one is a price list:
house 1000000
chair 2300
suitcase 600
pen 15
These data sources could be replaced by a database or a web service and the reasoning would be the same. In order to access those sources I/O needs to be performed and therefore the result will be embedded in the IO
type. Moreover, an optional result type (Maybe
) should be used in case we search for a non-existant key. Therefore the functions that retrieve data will be:
mkTable f = let mkPair (x:y:_) = (x, f y) in
fmap (mkPair . words) . filter (/= "") . lines
getItem :: String -> (String -> a) -> String -> IO (Maybe a)
getItem file f key = readFile file >>= return . lookup key . mkTable f
getTranslation :: String -> IO (Maybe String)
getTranslation = getItem "dict.txt" id
getPrice :: String -> IO (Maybe Int)
getPrice = getItem "prices.txt" read
We want to, given a product named in Portuguese, to have its price. The types of the results of those functions show that to access the data we want, we need to unwrap first the IO
type and then Maybe
. An attempt would be:
v1 :: String -> IO (Maybe Int)
v1 key = do
item <- getTranslation key
case item of
Nothing -> return Nothing
Just x -> getPrice x
The do
notation unwraps the IO
monad, and the Maybe
is unwrapped with a case
statement. Running this in ghci
:
Prelude> :l MaybeT.hs
*MaybeT> v1 "livro"
Nothing
*MaybeT> v1 "casa"
Just 1000000
*MaybeT>
It was necessary to, in this example, manually unwrap the Maybe
type embedded in IO
so as to call getPrice
on the result. Although in this case the effort was not very big, things can escalate quickly with more functions.
Let’s see a possible definition of MaybeT
:
This declaration shows that a single object named runMaybeT
is being held with the type m (Maybe a)
. It is the composition of a type m
we know nothing about, besides the fact it has also an instance of Monad
, and the Maybe
type we know, which is wrapped by m
. So the MaybeT
transformer is a way of accessing the innermost data bypassing the outer monad, which we don’t care about, without needing to manually unwrap it at every step, as the next example show:
v2 :: String -> IO (Maybe Int)
v2 key = runMaybeT $ do
item <- MaybeT $ getTranslation key
MaybeT $ getPrice item
It is not terribly shorter than the first version, but the advantages are clear when the number of steps increases. For each new function added to the chain a case
statement would have to be added to the first version, while in the second version the code is shorter and the flow is obvious. Besides, newtype
is a restricted version of data
that doesn’t exist at runtime: All this wrapping and unwrapping of MaybeT
seen in the code above will be elided by the compiler. Other monad transformers like EitherT
, ReaderT
, StateT
, etc. work in similarly, they let you abstract away the outer monad and work on the data you care about.
I am glad I bought this book. This insight alone made it worth for me.
]]>Lately I have been reading about searching in game trees. So a friend of mine sent me the “Escape from Zurg” paper, which talks about problem solving by tree searching with Haskell.
In a large class of problems one is given a start state and some predicate for a desired final state. Moreover, the rules that dictate how a successor state is generated from a previous one are also given. Take a board game for instance, like tic-tac-toe. There is the initial state (which is the empty board), the predicate for a desired state (a state in which tree pieces of mine are aligned), and rules to create one state from another (the rules of the game). Another example of such problems is the “Escape from Zurg” one, that is stated as follows:
Buzz, Woody, Rex, and Hamm have to escape from Zurg. They merely have to cross one last bridge before they are free. However, the bridge is fragile and can hold at most two of them at the same time. Moreover, to cross the bridge a flashlight is needed to avoid traps and broken parts. The problem is that our friends have only one flashlight with one battery that lasts for only 60 minutes (this is not a typo: sixty). The toys need different times to cross the bridge (in either direction):
TOY TIME Buzz 5 minutes Woody 10 minutes Rex 20 minutes Hamm 25 minutes Since there can be only two toys on the bridge at the same time, they cannot cross the bridge all at once. Since they need the flashlight to cross the bridge, whenever two have crossed the bridge, somebody has to go back and bring the flashlight to those toys on the other side that still have to cross the bridge. The problem now is: In which order can the four toys cross the bridge in time (that is, in 60 minutes) to be saved from Zurg?
This class of problems is usually solved by searching. The initial state and all the successors ultimately build a DAG (directed acyclic graph) that is called the search space. Some search spaces are small, like tic-tac-toe playing or even the “Escape from Zurg” puzzle. Others are large, like playing Reversi; even larger, like playing Chess; others are infinite. Needless to say that that are better searching ways than others. This same puzzle, for instance, was solved in Scheme by Ben Simon using the cool amb
operator. The amb
operator uses first-class continuations to backtrack and take another path in case the first one fails. It was an elegant solution for this puzzle, but it is not adequate for general searching because it backtracks blindly. There are others ways to search blindly, for instance depth-first search and breadth-first search.
In a depth-first search, we analyse the successors of a given state until there are no more successors to analyse, and then backtrack to a previous level of the tree. In a breadth-first search, we analyse the whole fringe of the tree (the horizon nodes) before expanding it one level further using the successor rules. This is good for infinite search spaces, because we will eventually find a solution if there is one. The implementation in Scheme is straightforward:
(define (depth-first states successors goal?)
(if (null? states)
#f
(let ((state (car states)))
(if (goal? state)
state
(depth-first (append (successors state)
(cdr states))
successors
goal?)))))
(define (breadth-first states successors goal?)
(if (null? states)
#f
(let ((state (car states)))
(if (goal? state)
state
(breadth-first (append (cdr states)
(successors state))
successors
goal?)))))
This is actually all we need for simple searches. Of course we need to supply the initial state, the procedure that generates successors and the goal predicate. These are specific for each kind of problem. Let’s see the Zurg problem procedures:
;; the type of the states found in our puzzle
(define-type state
(previous unprintable:) ;; previous state
near ;; toys in near shore
far ;; toys in far shore
flashlight ;; location of flashlight
time) ;; time consumed so far
(define (start-state)
(make-state #f
'(buzz woody rex hamm)
'()
'near
0))
(define (final-state? state)
(and (null? (state-near state))
(<= (state-time state) 60)))
;; at most two toys can travel across the bridge
;; the flashlight must be used in all crossings
(define (successors state)
(let ((orig (if (eqv? (state-flashlight state)
'near)
(state-near state)
(state-far state)))
(dest (if (eqv? (state-flashlight state)
'near)
(state-far state)
(state-near state))))
(map (lambda (toy-pair)
(let ((toy1 (car toy-pair))
(toy2 (cdr toy-pair)))
(make-next-state state
(remove toy2
(remove toy1 orig))
(ucons toy1
(cons toy2 dest))
(max (time-cost toy1)
(time-cost toy2)))))
(product orig orig))))
The previous procedures use some utilities:
(define (make-next-state state orig dest time)
(if (eqv? (state-flashlight state) 'near)
(make-state state orig dest 'far (+ (state-time state) time))
(make-state state dest orig 'near (+ (state-time state) time))))
;; the time each toy takes to cross the bridge
(define time-cost
(let ((costs '((buzz . 5)
(woody . 10)
(rex . 20)
(hamm . 25))))
(lambda (toy)
(let ((pair (assv toy costs)))
(and pair
(cdr pair))))))
(define (ucons a b)
(if (memv a b)
b
(cons a b)))
(define (product lis1 lis2)
(let lp1 ((lis1 lis1)
(res '()))
(if (null? lis1)
res
(let ((i1 (car lis1)))
(let lp2 ((lis2 lis2)
(res res))
(if (null? lis2)
(lp1 (cdr lis1) res)
(let ((i2 (car lis2)))
(if (member (cons i2 i1) res)
(lp2 (cdr lis2) res)
(lp2 (cdr lis2) (cons (cons i1 i2) res))))))))))
Our successors
procedure does not take time in account. So it is possible for a branch of the tree to go on indefinitely. To guarantee that we will arrive at a solution, we use a breadth-first search:
(define (print-path state)
(let loop ((state state)
(path '()))
(if state
(loop (state-previous state)
(cons state path))
(for-each println path))))
(print-path (breadth-first (list (start-state)) successors final-state?))
With the result:
#<state #14 near: (buzz woody rex hamm) far: () flashlight: near time: 0>
#<state #15 near: (rex hamm) far: (buzz woody) flashlight: far time: 10>
#<state #16 near: (woody rex hamm) far: (buzz) flashlight: near time: 20>
#<state #17 near: (woody) far: (rex hamm buzz) flashlight: far time: 45>
#<state #18 near: (buzz woody) far: (rex hamm) flashlight: near time: 50>
#<state #19 near: () far: (buzz woody rex hamm) flashlight: far time: 60>
If we change our successors
procedure a little, we can use depth-first search:
(define (successors2 state)
(let ((orig (if (eqv? (state-flashlight state)
'near)
(state-near state)
(state-far state)))
(dest (if (eqv? (state-flashlight state)
'near)
(state-far state)
(state-near state))))
(filter (lambda (s)
(<= (state-time s) 60)) ;; filtering out bad states
(map (lambda (toy-pair)
(let ((toy1 (car toy-pair))
(toy2 (cdr toy-pair)))
(make-next-state state
(remove toy2
(remove toy1 orig))
(ucons toy1
(cons toy2 dest))
(max (time-cost toy1)
(time-cost toy2)))))
(product orig orig)))))
(print-path (depth-first (list (start-state)) successors2 final-state?))
The advantage of changing the successors procedure is that depth-first searches are usually faster than breadth-first searches, in this case 483ms vs. 24630ms. Also, it uses less memory. So it is always a good idea to try to cut the search space as soon as possible.
Doing some research about compilers, interpreters and virtual machines, I have gathered some bibliography from several resources. Here it is, in no particular order: