Ballad of a Duck

==Preface==

Why do we bother to write computer programs at all?  Surely there must be a reason to undertake such a task.  In fact, I believe there to be several.

First and weakest of these I think is our desire to simplify a task.  Programming can greatly alleviate the tedium of simple, repetitive processes.  I can confidently say I think this is the reason about 99% of computer programs have been written, but also that it's not a particularly strong reason why people have done so and particularly not why they continue to do so.

Existing tools do such a good (or at last competent) job of this that there is little continuing reason to program such tools from the ground up.  In fact, many programming tasks amount to just slightly modifying these existing solutions.

Learning a programming language and computer system well enough to deliver a competent automation tool and then the task of actually doing it are not simple or easy.  They require years of study, and any serious endeavor likely entails years of fine-tuning.  A great deal of tedium can be justified in place of this expenditure of effort.

No, we cannot reasonably say that people go into computer programming just to make their lives easier.  That job has been accomplished, and even had it not, the personal payoff is very rarely worth it.

However, we are creatures of pride, and we frequently see opportunities to improve on or best the work of others, especially when presented with a solution that is at best competent. Now, of course we may never succeed at doing so, but our belief that we can keeps us trying.

One need only look at the proliferation of "standards" to see this in action.  How many instant messaging protocols does the world need, really?  And yet, people keep striving to better the existing stalwarts.  This is a good thing: it keeps the world of computers fresh and interesting and (generally speaking) continually improving.

Pride is a good reason to program, but also a dangerous one.  A prideful programmer can become convinced that his or her creations are superior regardless of their objective merit.

Of course, it's possible to offset this hazard by filling an unmet need.  This is an increasingly rare, but powerful motivation.  Imagine the drive to create a complete cross-platform office suite for open source computing platforms.  Those programmers had the pride to say they could do it, and nothing to compare against to demotivate them.

But the most important reason we write computer programs is the simplest, and one that cannot easily be discouraged by the body of existing work, or even a lack of overwhelming pride in ourselves.  Quite simply, we write computer programs to find out if we can.  We write more to find out how far we can go.

This is why I began programming years ago.  I'm not sure I've yet found a limit.  What will yours be?  I hope you'll never find out, but if you want to push yourself, keep reading.

==My Approach==

I am a self-taught computer programmer.  My knowledge has been pieced together from bits of code and often sarcastic internet rants about best practices, and my willingness to ask questions.

I will try to guide you, the readers, through some of the basics, but I expect you to go out and explore on your own, and answer the basics.  Don't worry, I'll help you with the details.

If this approach bothers you, then stop reading here.  I don't believe in spoon-feeding you information.  Anytime I've done that I've never been able to tell who was learning and who was just regurgitating code.  If you see yourself in that latter description, try to change.  If you can't, there are myriad options out there that will give you the easy answers you seek.

==Language==

Lots of computer programming books teach you how to write code in Java or C++ or C# because those are useful languages and all basically the same.  They are eminently useful for streamlining repetitive tasks and getting work done, which we know is what computer programs are written ''to do''.  Why shouldn't they teach these languages to you?

They shouldn't because that's not ''why'' we learn to write computer programs.  Sure, C++ can be a huge challenge, but not the way it's taught or used by most, and many of its challenges lie in minutiae.  Java and C# are comparatively boring languages.  Most of their mastery lies in knowing which library to use and remembering long names.

All of those languages deal with a very simple concept: we have a piece of data X and we tell the computer to do Y to it, then we tell it to do Z to it in a linear fashion.  The piece of data keeps getting changed until it's what we need.  This is what we typically refer to as "imperative" programming, and it encompasses the majority of widely used programming languages.

But we often hear programmers talk about "functional" programming, and they call it difficult and present it as generally unfathomable.  We still transform data in a functional programming language, but it encourages us to find different ways to accomplish that goal, and the conventional wisdom is that this is too difficult.

It's for precisely this reason that a functional programming language will be my choice.  I have made a choice that I firmly believe represents the best balance of characteristics: it has no confusing fragmented implementations or libraries, and yet supports solid tools.  It also boasts the advantage of a more direct syntax for expressing a number of concepts that the aforementioned mainstream programming languages have to come at in rather oblique ways.

I want you to continue reading because you like that people have said functional programming is too hard; you like proving them wrong and proving to yourself that you can do it.

==Data==

I have said that programming at its heart is transforming one piece of data into another.  It behooves us, then, to start out by taking some time to look at what data really is.

Data are all of the tiny points of information that make up life.  The meat of the data world are numbers.  We deal with numbers constantly, and so too must programmers.

We deal most commonly with round numbers, or what a programmer would call integers.  Integers are easy and direct.  We can relate them to solid everyday objects, and as in written communication, integers are very easy to symbolize in computer programs.

Less easy are non-whole numbers, or as programmers would say, floating-point numbers.  These are fractions of things: 3.4 km to the library; half a pizza left in the fridge.  Humans don't usually have much difficulty working with these kind of numbers, but computers, with their binary brains do.  In fact, while numbers like these can be represented accurately, it takes a lot of computational power to do so.  To address this, computers store an approximation of these numbers which as the number increases becomes less accurate. 

This will likely not be a huge obstacle at this level, but it does warrant consideration.  The money example is a perfect one.  If you're keeping track of money, there's a strong temptation to track dollars, and use floating point numbers to account for pennies.  Knowing that you can instead count using integers to represent pennies, you should do so to avoid any inaccuracy as calculations are made on those values.

Aside from numbers, we can represent text with two different types of data.  The simplest is a character.  For the sake of simple Latin-based characters, characters can be thought of as simply integers between 0 and 255, where each number represents a unique character.  Strings are a sequence of characters, and generally are far more useful, though necessarily take a little more getting used to working with. 

==Notes on Code Organization==

The biggest expenditure of time in programming is not writing, but rather reading code.  As we explore increasingly complex programs, it will be important for us to find ways to organize our code, both to make it easier to read, and easier to fix our errors once they're found.   

Two fundamental units of organization exist.  These will be explored later in greater detail, but some theory is called for first.

===Functions===

Functions give a name to a transformation of one piece of information into another.  Rather than simply writing the same code repeatedly throughout our program, we can name a given calculation.  This avoids tedious retyping or copy and paste, but more importantly, lets us tell the reader of the code what we're calculating, rather than how we're doing it.  As well, improvements to a given set of code can be made in one place, and the benefits apply everywhere that function is used.

Given that we will be using a functional programming language, you should expect it to be exceptionally easy to create new functions.  You will also find that many existing functions are provided to accomplish basic tasks.  We will use many of these, but you may also end up rewriting others to learn how they work.

===Modules===

As we accumulate more and more functions and data, we can expect naming to become increasingly troublesome.  To keep related data and functions grouped, we will use modules.

As there are a number of existing functions, there are a number of different modules provided which help to group those functions together.  The one you'll encounter most frequently is Pervasives, which includes a great number of common and highly useful functions.

Any module may, for convenience's sake, be opened, allowing its contents to be directly accessed.  This is the case with Pervasives, but otherwise use of this facility should be with discretion.

As with functions, modules are easily created and experimented with.  We will use them extensively as we go.

==The Language==

So far everything has been in English.  There hasn't been a single bit of code in sight.  That's intentional.  I wanted your attention before I started throwing distracting code examples at you.  But, as that's about to begin, it's worth taking a bit of time to talk about the other language that will be in use.

OCaml is a functional programming language.  It is a very syntax-heavy language, and there's a lot to learn.  Fortunately, OCaml lets us learn this as we go, rather than dumping it all on us at the very beginning.  In other words, it can be as simple or as complex as we need it to be to delve into the world of computer programming.

OCaml is a compiled programming language.  This means that our OCaml programs are translated to machine code which can be natively executed by our computers without any further translation necessary.  This makes programs run very fast, but means that we need to compile programs and then run them.

Fortunately, OCaml also supports something called a "bytecode interpreter" wherein OCaml programs are converted to an intermediate format and then run.  This is much slower than native compilation, but can yield quicker results.  On top of this, OCaml provides an "interactive toplevel" interpreter, which accepts small chunks of code, evaluates them and spits out the result.  Inadequate for composing large programs, this tool is nevertheless invaluable for letting us play with core concepts and test our understanding before implementing larger programs dependent on understanding those concepts.  We will use this extensively.

OCaml is statically typed.  All data have types.  We know that functions transform one piece of data into another.  Functions are very strict about the type of data fed to them.  If the types are incorrect, the program will not compile or run at all.  OCaml will provide an error indicating the source of the error.

These type errors are very useful for identifying both simple and more complex logical errors in a program.  Though this does not hold universally true, many believe that an OCaml program that runs is likely to be free of errors simply by virtue of getting past the type checker.

The OCaml tools and manuals can be found at http://caml.inria.fr.  This document will not cover the installation process, which is very straightforward for both Windows, Mac and Linux/*nix users.

==Data Representation==

Previously I have spoken about data in OCaml.  We discussed integers, floating point numbers, characters and strings.  It should not be surprising that all of these have straightforward representations within OCaml programs.  Of course, these types and most of their representations are common to a wide variety of different programming languages.

Integers could scarcely be simpler.  Both positive and negative integers have easy representations.

{| style="font-size: 14pt"
| <tt>42</tt>
|-
| <tt>-6</tt>
|}

Floating point numbers are similarly simple, but do have one wrinkle: if the floating point number in question is a whole number, the trailing zero after the decimal point may be elided.  A leading zero must precede the decimal point if the floating point number is between <tt>1</tt> and <tt>-1</tt>.  Scientific notation is also available.

{| style="font-size: 14pt"
| <tt>3.14159</tt>
|-
| <tt>-5.4</tt>
|-
| <tt>7.0</tt>
|-
| <tt>7.</tt>
|-
| <tt>0.2378</tt>
|-
| <tt>1.23e-5</tt>
|}

Characters are enclosed by single quotes and contain a single character.  A couple of exceptions exist to this.  Should we need to represent the single quote character, we can escape it within the single quotes with a backslash.  Additionally, a backslash followed by an <tt>n</tt> represents a newline character.  Though it may also appear odd, a space character can be represented by a space within single quotes.

{| style="font-size: 14pt"
| <tt>'a'</tt>
|-
| <tt>'Z'</tt>
|-
| <tt>'4'</tt>
|-
| <tt>'"'</tt>
|-
| <tt>'\''</tt>
|-
| <tt>' '</tt>
|-
| <tt>'\n'</tt>
|}

Strings are represented by zero or more characters enclosed within double quotes.  As in characters we represented a single quote with the backslash, so a double quote can be included in a string.  The same applies for the newline.

{| style="font-size: 14pt"
| <tt>""</tt>
|-
| <tt>"a"</tt>
|-
| <tt>"Ballad of a Duck"</tt>
|-
| <tt>"Ballad of a Duck\n"</tt>
|-
| <tt>"\"Ballad of a Duck\"\n"</tt>
|}

===Questions===

1. Which is an integer?

{| style="font-size: 14pt"
| a) || <tt>4.</tt> 
|-
| b) || <tt>1.3</tt>
|-
| c) || <tt>27</tt>
|}

2. Which is a valid character representation?

{| style="font-size: 14pt"
| a) || <tt>&#39;&#39;</tt> 
|-
| b) || <tt>'\N'</tt>
|-
| c) || <tt>'R'</tt>
|}

3. Which of the following represents the supplied string? Supplied string: <tt>"Hello, world!"</tt>

{| style="font-size: 14pt"
| a) || <tt>"Hello, world!"</tt> 
|-
| b) || <tt>"\"Hello, world!\""</tt>
|-
| c) || <tt>"'Hello, world!'"</tt>
|}

==Expressions==

Having discussed basic data types and their representations, it's important to talk about a word we'll be using a lot of: expressions.

Already simple data representations form basic expressions.  Put very simply, an expression is a chunk of code which has a value.  An integer, a floating-point number, a character and a string all have a readily apparent value.

Operations on these basic values can yield other values.  We can think of this operation and the values it works on as an expression.  A very simple example would be basic integer math.  A few examples follow.

{| style="font-size: 14pt"
| <tt>1</tt>
|-
| <tt>1 + 1</tt>
|-
| <tt>3 - 2</tt>
|-
| <tt>4 * 5</tt>
|-
| <tt>8 / 4</tt>
|}

Or course, the same can be done with floating point numbers, though OCaml uses distinct representations for these operations, and one cannot mix integers and floating-point numbers.

{| style="font-size: 14pt"
| <tt>1.0</tt>
|-
| <tt>1.0 +. 1.3</tt>
|-
| <tt>3. -. 2.1</tt>
|-
| <tt>4.6 *. 5.2</tt>
|-
| <tt>8.7 /. 3.</tt>
|}

Understanding that one can combine values with operations to form more complex expressions is crucial to becoming a proficient programmer, because it will allow you to pull apart seemingly complex code and understand its constituent pieces.

The composition of expressions is recursive.  That is to say, if both <tt>1</tt> and <tt>1 + 1</tt> are expressions, then it stands to reason that any two expressions can be used with <tt>+</tt>, for instance.  Parentheses can be used to group an expression and make it more apparent what is going on.  Understanding the order in which operations are applied often renders this unnecessary.

{| style="font-size: 14pt"
| <tt>1</tt>
|-
| <tt>1 + 1</tt>
|-
| <tt>(1 + 1) + 3</tt>
|-
| <tt>1 + 1 + 3</tt>
|-
| <tt>(1 - 2) * (3 + 2)</tt>
|-
| <tt>(1 - (1 + 1)) * (3 + 2)</tt>
|}

In the case of that last example, we can process the individual expressions that compose it as follows.

{| style="font-size: 14pt"
| <tt>(1 - (1 + 1)) * (3 + 2)</tt>
|-
| <tt>(1 - (2)) * (5)</tt>
|-
| <tt>(1 - 2) * 5</tt>
|-
| <tt>(-1) * 5</tt>
|-
| <tt>-1 * 5</tt>
|-
| <tt>-5</tt>
|}

===Questions===

1. Is the following expression valid?  <tt>4.3 *. 3</tt>

2. How many expressions are present in the following expression?  <tt>(4.3 *. 2. +. 47.1) /. 2.3 -. 1.2</tt> 

{| style="font-size: 14pt"
| a) || 2
|-
| b) || 3
|-
| c) || 4
|-
| d) || b and c
|-
| e) || a, b and c
|}


3. What is the value of the expression in question 2?

==Testing Expressions==

OCaml's top-level interactive interpreter is a perfect place to test expressions.  It provides an immediate response without having to write, compile and run an entire program.  It also conveniently shows us the types of expressions.

A snippet from the toplevel follows.  The <tt>#</tt> character is used as a prompt from the interpreter.

<pre># 4 ;;
- : int = 4
# 4 + 1 ;;
- : int = 5
# "hello" ;;
- : string = "hello"
# 1. ;;
- : float = 1.
# 1. +. 3.4 ;;
- : float = 4.4
#</pre>

There is little else to be said about this, except of course to encourage experimentation.

==Functions==

Thus far we know that functions are a way of transforming one piece of data into another.  We've also looked at some basic types of data.  As we take the next step, we'll see that in a functional programming language like OCaml the two are one and the same, discover a new type of value, and realize that functions are old hat.  Let's write our own function.

Functions give a name to a particular transformation of data.  However, they don't necessarily need names.  Let's look at a function which increments a number <tt>x</tt>.  The <tt>fun</tt> keyword in the following is a piece of OCaml syntax, as is the arrow (<tt>-></tt>).

<pre>fun x -> x + 1</pre>

We can test this in the interpreter.  Upon doing so, we'll notice a new type <tt>int -> int</tt>.  This type describes a function which transforms an integer into an integer.  Based on the use of <tt>+</tt>, OCaml can infer that this function is meant to work on the <tt>int</tt> type.

<pre># fun x -> x + 1 ;;
- : int -> int = <fun>
#</pre>

As the left-hand side of a function definition like this can contain any expression, we can easily make this a more complex transformation.  Consider, for example, the following.

<pre># fun x -> (x + 1) * 3 - 1 ;;
- : int -> int = <fun>
#</pre>

===Applying a function===

Functions are meant to transform data, but in order to do that, we have to apply the function to a value.  This is done quite simply by following the function with a value.  The function, being an expression, will be enclosed in parentheses.

<pre># fun x -> (x + 1) * 3 - 1 ;;
- : int -> int = <fun>
# (fun x -> (x + 1) * 3 - 1) 4 ;;
- : int = 14
# (fun x -> (x + 1) * 3 - 1) 10 ;;
- : int = 32
#</pre>

The value to which the function is being applied is often known as an argument.

===Multiple arguments===

Functions are values, and functions transform one value into another.  This leads us to the astounding realization that a function can return another function.  While functions can take only a single argument, this can be helpful in simulating multiple arguments.  Consider the following.

<pre>fun x -> (fun y -> x * y)</pre>

It's worth noting that OCaml syntax does not strictly require the parentheses.

<pre>fun x -> fun y -> x * y</pre>

The type of this function would be <tt>int -> (int -> int)</tt> or eliding the parentheses, <tt>int -> int -> int</tt>.  We can explore and confirm this inference using the interpreter.  Please note that again, we were able to elide a set of parentheses in the final application of the function.

<pre># fun x -> fun y -> x + y;;
- : int -> int -> int = <fun>
# fun x -> fun y -> x * y ;;
- : int -> int -> int = <fun>
# (fun x -> fun y -> x * y) 3 ;;
- : int -> int = <fun>
# ((fun x -> fun y -> x * y) 3) 2 ;;
- : int = 6
# (fun x -> fun y -> x * y) 3 2 ;;
- : int = 6
#</pre>

===Exercise===

Write a function which returns the sum of three input floating-point numbers.

==Naming==

Values, but even moreso functions, are less than useful without having names.  By giving values names, we can reuse them easily.  This is easily accomplished in OCaml using a <tt>let</tt> binding.  Meaningful names are critical to understanding what a computer program does and how it goes about accomplishing that.

<pre>let a = 42</pre>

<pre>let product = 
   fun x -> fun y -> x * y</pre>

<pre># let a = 42 ;;
val a : int = 42
# let product =
     fun x -> fun y -> x * y ;;
val product : int -> int -> int = <fun>
# product a a ;;
- : int = 1764
# let times_two = product 2 ;;
val times_two : int -> int = <fun>
# times_two 5 ;;
- : int = 10
#</pre>

It should not be surprising that since the <tt>product</tt> function returns a function that we can bind the resulting function to another name.  It may come as a pleasant surprise, though, that <tt>let</tt> gives us a more convenient way to create functions.

<pre># let product x y = x * y ;;
val product : int -> int -> int = <fun>
# let times_two = product 2 ;;
val times_two : int -> int = <fun>
# times_two 5 ;;
- : int = 10
#</pre>

===Scope===

Thus far, we've looked at naming which takes effect for the entirety of a program.  That is to say, if we give a name of <tt>foo</tt> to the value <tt>42</tt>, it will have that value for the rest of the program.  We can use that name for another value later on, even if that value has a different type, but either way, we now have to keep track of that name for the rest of the program.

We can locally bind a name to a value, though, so that it only affects a small subset of the entire program.  Consider a function which changes from farenheit to celsius.

<pre># let f_to_c f_temp =
     (f_temp -. 32.) /. 1.8;;
val f_to_c : float -> float = <fun>
# f_to_c 212.;;
- : float = 100.</pre>

This works, but the factor to divide by is not documented.  We can document it simply by giving it a name.

<pre># let f_to_c f_temp =
     let conversion_factor = 1.8 in
        (f_temp -. 32.) /. conversion_factor;;
val f_to_c : float -> float = <fun>
# f_to_c 212.;;
- : float = 100.</pre>

Any further attempt to use <tt>conversion factor</tt> will fail.

<pre># conversion_factor;;
Characters 0-17:
  conversion_factor;;
  ^^^^^^^^^^^^^^^^^
Error: Unbound value conversion_factor</pre>

Functions may also be locally bound.

<pre># let f_to_c f_temp =
     let conversion_factor = 1.8 in
        (f_temp -. 32.) /. conversion_factor
  in
     f_to_c 212.;;
- : float = 100.</pre>

All of which leads us to the following being possible.  Of course, we probably shouldn't do something like this in this kind of case, but it's still possible, and potentially quite useful for small helper functions with a limited scope of usefulness.

<pre># let c_temp =
     let f_to_c f_temp =
        let conversion_factor = 1.8 in
           (f_temp -. 32.) /. conversion_factor
     in
        f_to_c 212.
  in
     int_of_float c_temp;;
- : int = 100</pre>

===Another syntax note===

I have continued to use <tt>;;</tt> with no explanation.  This piece of syntax in OCaml programs separates constructs where the separation between them is otherwise ambiguous.  There are, however, various situations in which <tt>;;</tt> is not necessary, as the separation is unambiguous.  <tt>let</tt> bindings are one such example.

<pre># let product x y = x * y
  let times_two = product 2 ;;
val product : int -> int -> int = <fun>
val times_two : int -> int = <fun>
# times_two 4 ;;
- : int = 8
#</pre>

==Boolean Expressions==

So far we've looked at basic values, arithmetic expressions, and function calls.  All of these are expressions, but not all expressions fall into these few types.  Among the most useful expressions are boolean expressions: that is to say, expressions which evaluate to either true or false.  While arithmetic expressions involved operators like <tt>+</tt> and <tt>-</tt>, we'll see some familiars from math in boolean expressions as well.  

{| style="font-size: 14pt"
| <tt>=</tt> and <tt> <> </tt> 
|-
| <tt> > </tt> and <tt> >= </tt> 
|-
| <tt> < </tt> and <tt> <= </tt> 
|-
| <tt>&#124;&#124;</tt> 
|-
| <tt>&amp;&amp;</tt> 
|}

==Answers==

===Data Representation===

1. c

2. c

3. b

===Expressions===

1. no, it isn't

2. e

3. approximately 23.0173