L4/L5/S1/Sacro-iliac fusion
L4/L5/S1 fusion performed 15 March 2011
Sacro-iliac fusion performed 01 November 2011
After a subsequent meeting with an specialist inter-state, the diagnosis of obturator neuropathy has been revised. Obturator neuropathy rarely occasions in isolation[1]. The true diagnosis is more sinister, with the obturator neuropathy occurring as one of many symptoms.
Reconstructive surgery is required.
A talk on the list fold functions (fold left and fold right), delivered to Brisbane Functional Programming Group on Tuesday 23 April 2013.
After 19 surgeries1 and 5 years of searching for the source of my chronic pain syndrome, which started with a sporting injury in 2007, I have been found to have a condition called Obturator Neuropathy — a source of chronic pain affecting athletes.
Unfortunately, many specialists are unaware of this condition and so may not recognise the correct diagnosis, which has been my case. Obturator Neuropathy typically affects those engaged in kicking sports and especially, Australian Rules football. Although I was playing Australian Rules football at the time of my injury, I live in Brisbane, where the sport is less popular than in other cities such as Melbourne and Sydney, where the condition is more recognised. I have recently learned that many more specialists in these cities are aware of this insidious disease, while I have yet to find anyone in Brisbane who even know it exists — I suppose this set of circumstances came together to delay my correct diagnosis for many years.
This article is the first of my writings on this condition, as at this time, it is still currently unresolved. I am planning to meet with many specialists in the next few days to discuss surgical management. Later, I intend to raise greater awareness of this condition in the hope that other athletes, professional or otherwise, needn’t go through the dramas that I have done in these last few years.
My pain is now so severe that I am unable to perform my normal duties for my employer. Thankfully, my employer is awesome and understanding of my plight and I am committed to resolving this matter as soon as possible so that I can contribute back my highest level of performance. I am thankful to others in their understanding and I apologise to those who have sometimes been on “the wrong end of the stick” of my frustrations especially when I am having a “bad day” with pain. I am also usually taking narcotic medication during these times, so my recollection of the events is typically blurry to me.
If you are ever inflicted with this condition, I highly recommend these publications, with most recommended appearing first:
Bradshaw, Chris, et al. “Obturator Nerve Entrapment A Cause of Groin Pain in Athletes.” The American journal of sports medicine 25.3 (1997): 402-408. (link)
Bradshaw, Chris, and Paul McCrory. “Obturator nerve entrapment.” Clinical Journal of Sport Medicine 7.3 (1997): 217-219. (link)
Tipton, John Sison. “Obturator neuropathy.” Current reviews in musculoskeletal medicine 1.3-4 (2008): 234-237. (link)
Harvey, Gregory, and Simon Bell. “Obturator neuropathy: an anatomic perspective.” Clinical orthopaedics and related research 363 (1999): 203-211. (link)
Busis, Neil A. “Femoral and obturator neuropathies.” Neurologic clinics 17.3 (1999): 633-653. (link)
Koulouris, George. “Imaging review of groin pain in elite athletes: an anatomic approach to imaging findings.” American Journal of Roentgenology 191.4 (2008): 962-972. (link)
Sorenson, Eric J., Joseph J. Chen, and Jasper R. Daube. “Obturator neuropathy: causes and outcome.” Muscle & nerve 25.4 (2002): 605-607. (link)
Kitagawa, Ryan, et al. “Surgical management of obturator nerve lesions.” Neurosurgery 65.4 (2009): A24-A28. (link)
Arnold, William David, and Bakri H. Elsheikh. “Entrapment Neuropathies.” Neurologic Clinics (2013). (link)
Orchard, John, et al. “Pathophysiology of chronic groin pain in the athlete.” Int J Sports Med 1.1 (2000). (link)
Anagnostopoulou, Sofia, et al. “Anatomic variations of the obturator nerve in the inguinal region: implications in conventional and ultrasound regional anesthesia techniques.” Regional anesthesia and pain medicine 34.1 (2009): 33-39. (link)
21 surgeries under a strict definition of the term “surgery” but let’s stick with 19 :)↩
One of the very nice properties of type-safe, functional source code or API is that “an example usage of that API …” can almost always be answered with “anything that type-checks.” Now for some people and for some libraries, this answer is unsatisfactory, offensive even — they demand an example dammit!
But what they think I am going to do? Do they really think I have a library of examples in my head that I am holding hostage? Do they think that I am being spiteful toward them by withholding this library of knowledge that I possess and they do not? No, what I would do here is exactly what they are very capable of doing — they can find any type-checking program. In fact, this is the tool support that I aspire to so that I do not have to maintain a “library of examples” in my own head.
By appeasing their demand for “example usages of …”, if I were to do such an unfortunate thing, I am disservicing them. I am taking away their opportunity to develop the skills to answer this question for themselves. I am not even giving a good answer to the specifics of the question. It is not “a good example” of anything at all. It is the process by which the example is derived that is useful and nothing else.
So go on, try it. Create yourself a type-checking program. You may be a bit uncomfortable with the much higher degree of tool support in this environment. All I can say is, embrace it, cherish it even. Go.
The subject of lane-splitting on a motorcycle often comes up in discussion. In Australia, the legality of lane-splitting is not absolute. For example, under some circumstances, such as two (or even three) motorcycles sharing a lane, this manouvre may be legal (further specifics apply). Under some other circumstances, lane-splitting is illegal.
Below are verbatim excerpts of Transport Operations (Road Use Management) Act 1995; Transport Operations (Road Use Management-Road Rules) Regulation 1999 that are relevant to lane-splitting. The name of this legislation is sometimes abbreviated to TORUM. TORUM applies to the state of Queensland and is derived from the Australian Road Rules (ARR).
Other Australian state and territory road use legislation is also derived from the ARR. Although these sections have been excerpted directly from TORUM, they can also be found in the ARR (under the same sections) and also in the road use legislation for each Australian state/territory.
A driver on a multi-lane road must not move from 1 marked lane to another marked lane by crossing a continuous line separating the lanes unless–
There are many types of functors. They can be expressed using the Scala programming language.
map or fmap.// covariant functor
trait Functor[F[_]] {
def fmap[A, B](f: A => B): F[A] => F[B]
}contramap.// contravariant functor
trait Contravariant[F[_]] {
def contramap[A, B](f: B => A): F[A] => F[B]
}xmap. Also known as invariant functors.// exponential functor
trait Exponential[F[_]] {
def xmap[A, B](f: (A => B, B => A)): F[A] => F[B]
}apply or <*>.// applicative functor (abbreviated)
trait Applicative[F[_]] {
def apply[A, B](f: F[A => B]): F[A] => F[B]
}bind, flatMap or =<<.// monad (abbreviated)
trait Monad[F[_]] {
def flatMap[A, B](f: A => F[B]): F[A] => F[B]
}extend, coflatMap or <<=.// comonad (abbreviated)
trait Comonad[F[_]] {
def coflatMap[A, B](f: F[A] => B): F[A] => F[B]
}Sometimes I am asked how to remember all of these and/or determine which is appropriate. There are many answers to this question, but there is a common feature of all of these different types of functor:
They all take an argument that is some arrangement of three type variables and then return a function with the type F[A] => F[B].
I memorise the table that is the type of the different argument arrangements to help me to determine which abstraction might be appropriate. Of course, I use other methods, but this particular technique is elegant and short. Here is that table:
| functor | argument arrangement |
|---|---|
| covariant | A => B |
| contravariant | B => A |
| exponential | (A => B, B => A) |
| applicative | F[A => B] |
| monad | A => F[B] |
| comonad | F[A] => B |
We can see from this table that there is not much reason to emphasise one over the other. For example, monads get lots of attention and associated stigma, but it’s undeserved. It’s rather boring when put in the context of a bigger picture. It’s just a different arrangement of its argument (A => F[B]).
Anyway, this table is a good way to keep a check on the different types of abstraction and how they might apply. There are also ways of deriving some from others, but that’s for another rainy day. That’s all, hope it helps!
Everyone has seen a naïve fibonacci implementation
object FibNaïve {
def fibnaïve(n: BigInt): BigInt =
if(n <= 1)
n
else {
val r = fibnaïve(n - 1)
val s = fibnaïve(n - 2)
r + s
}
}While this implementation is elegant, it is exponential in time with respect to n. For example, computing the result of fibnaïve(4) will result in the unnecessary re-computation of values less than 4. If we unravel the recursion, computation occurs as follows:
fibnaïve(4)
= fibnaïve(3) + fibnaïve(2)
= (fibnaïve(2) + fibnaïve(1)) + (fibnaïve(1) + fibnaïve(0))
= ((fibnaïve(1) + fibnaïve(0)) + fibnaïve(1)) + (fibnaïve(1) + fibnaïve(0))This algorithm calculates for fibnaïve(2) twice, which ultimately results in a lot of repeated calculations, especially as n grows. What we would like to do is trade some space to store previous stored values for a given n. We can achieve this by looking up the argument value in a table and if it has already been computed, we return it then carry on, but if it hasn’t, we compute the result by calling fibnaïve, store it in the table, then return it. This technique is called memoisation.
As a first cut, let’s solve fibonacci with a helper function that passes a Map[BigInt, BigInt] around in the recursion. This map will serve at the memoisation table.
object FibMemo1 {
type Memo = Map[BigInt, BigInt]
def fibmemo1(n: BigInt): BigInt = {
def fibmemoR(z: BigInt, memo: Memo): (BigInt, Memo) =
if(z <= 1)
(z, memo)
else memo get z match {
case None => {
val (r, memo0) = fibmemoR(z - 1, memo)
val (s, memo1) = fibmemoR(z - 2, memo0)
(r + s, memo1)
}
case Some(v) => (v, memo)
}
fibmemoR(n, Map())._1
}
}We have traded space (the memoisation table) for speed; the algorithm is more efficient by not recomputing values. However, we have sacrificed the elegance of the code. How can we achieve both elegance and efficiency?
The previous code (fibmemo1) has passed state through the computation. In other words, where we once returned a value of the type A, we are accepting an argument of the type Memo and returning the pair (A, Memo). The state in this case is a value of the type Memo. We can represent this as a data structure:
case class State[S, A](run: S => (A, S))Our fibmemoR function which once had this type:
def fibmemoR(z: BigInt, memo: Memo): (BigInt, Memo)…can be transformed to this type:
def fibmemoR(z: BigInt): State[Memo, BigInt]Let’s write our new fibonacci function:
object FibMemo2 {
type Memo = Map[BigInt, BigInt]
def fibmemo2(n: BigInt): BigInt = {
def fibmemoR(z: BigInt): State[Memo, BigInt] =
State(memo =>
if(z <= 1)
(z, memo)
else memo get z match {
case None => {
val (r, memo0) = fibmemoR(z - 1) run memo
val (s, memo1) = fibmemoR(z - 2) run memo
(r + s, memo1)
}
case Some(v) => (v, memo)
})
fibmemoR(n).run(Map())._1
}
}Ew! This code is still rather clumsy as it manually passes the memo table around. What can we do about it? This is where the state monad is going to help us out. The state monad is going to take care of passing the state value around for us. The monad itself is implemented by three functions:
The map method on State[S, A].
The flatMap method on State[S, A].
The insert function on the object State that inserts a value while leaving the state unchanged.
I will also add three convenience functions:
eval method for running the State value and dropping the resulting state value.
get function for taking the current state to a value. (S => A) => State[S, A]
mod function for modifying the current state. (S => S) => State[S, Unit]
Here goes:
case class State[S, A](run: S => (A, S)) {
// 1. the map method
def map[B](f: A => B): State[S, B] =
State(s => {
val (a, t) = run(s)
(f(a), t)
})
// 2. the flatMap method
def flatMap[B](f: A => State[S, B]): State[S, B] =
State(s => {
val (a, t) = run(s)
f(a) run t
})
// Convenience function to drop the resulting state value
def eval(s: S): A =
run(s)._1
}
object State {
// 3. The insert function
def insert[S, A](a: A): State[S, A] =
State(s => (a, s))
// Convenience function for taking the current state to a value
def get[S, A](f: S => A): State[S, A] =
State(s => (f(s), s))
// Convenience function for modifying the current state
def mod[S](f: S => S): State[S, Unit] =
State(s => ((), f(s)))
}We can see that the flatMap method takes care of passing the state value through a given function. This is the ultimate purpose of the state monad. Specifically, the state monad allows the programmer to pass a state (S) value through a computation (A) without us having to manually handle it. The map and insert methods complete the state monad.
How does our fibonacci implementation look now?
object FibMemo3 {
type Memo = Map[BigInt, BigInt]
def fibmemo3(n: BigInt): BigInt = {
def fibmemoR(z: BigInt): State[Memo, BigInt] =
if(z <= 1)
State.insert(z)
else
for {
u <- State.get((m: Memo) => m get z)
v <- u map State.insert[Memo, BigInt] getOrElse
fibmemoR(z - 1) flatMap (r =>
fibmemoR(z - 2) flatMap (s => {
val t = r + s
State.mod((m: Memo) => m + ((z, t))) map (_ =>
t)
}))
} yield v
fibmemoR(n) eval Map()
}
}Now we have used the three state monad methods to pass the memo table through the computation for us - no more manual handling of passing that memo table through to successive recursive calls.
Scala provides syntax for the type of computation that chains calls to flatMap and map. It is implemented using the for and yield keywords in what is called a for-comprehension. The for-comprehension syntax will make the calls to flatMap and map, while allowing a more imperative-looking style. For example, where we once wrote code such as x flatMap (r =>, we will now write r <- x inside the for-comprehension.
How does this look?
object FibMemo4 {
type Memo = Map[BigInt, BigInt]
def fibmemo4(n: BigInt): BigInt = {
def fibmemoR(z: BigInt): State[Memo, BigInt] =
if(z <= 1)
State.insert(z)
else
for {
u <- State.get((m: Memo) => m get z)
v <- u map State.insert[Memo, BigInt] getOrElse (for {
r <- fibmemoR(z - 1)
s <- fibmemoR(z - 2)
t = r + s
_ <- State.mod((m: Memo) => m + ((z, t)))
} yield t)
} yield v
fibmemoR(n) eval Map()
}
}This is a lot neater as the memoisation table is handled by the state monad. In fact, it is starting to look like the original naïve solution. We are no longer manually handling the state transitions, which allows us to express the essence of the problem and without the calculation speed blow-out.
Where you once may have use var, consider if the state monad is instead more appropriate.
filter functionThe filter function is one that accepts a list as an argument, keeping all elements that satisfy a given predicate, discarding all others and returns the resulting list. For example, I might use the filter function in Haskell to keep all even elements in a list:
λ> filter even [2,3,6,2,4,7,6,75,22]
[2,6,2,4,6,22]or perhaps using Scala:
scala> List(2,3,6,2,4,7,6,75,22) filter (_ % 2 == 0)
res0: List[Int] = List(2, 6, 2, 4, 6, 22)In both cases, the list structure under examination is a cons list.
When I teach functional programming, we are usually implementing the filter function on our own cons list using Haskell1 on the first day. Having done this enough times now, with both Haskell and Scala, I observe a recurring pattern.
The usual solutions are given either with explicit pattern-matching along with explicit recursion:
fiilter _ [] = []
fiilter p (h:t) = if p h then h:fiilter p t else fiilter p t…or by using the provided foldRight function, which abstracts the pattern-matching and recursion for cons lists:
fiilter p x = foldRight (\a b -> if p a then a:b else b) [] xfilter as an exerciseWhichever solution is given, they are both correct. However, almost invariably, at this stage in the exercise, there is a developing suspicion that this solution can be done better. I am usually quizzed about how to improve the solution. For example, in the pattern-matching solution, both sides of the if branch repeat the code fiilter p t. Indeed, even in the foldRight solution, there is application to the value b on both sides of the if branch – a classic example of repetitive code (we functional programmers take the DRY principle seriously, even obsess over it!).
So let’s get on with the refactor. Since we are using pure functional programming, we are able to deploy equational reasoning. In other words, we are able to shuffle our expressions around, so long as we have an equivalent expression, because we are void of side-effects.
Let’s take a quick diversion for a minute and imagine if we did not have this guarantee and suppose we were to tidy up this code:
if p then f x else f yThis code can be refactored to remove the repetition of application of the function f:
f (if p then x else y)However, imagine if f performed a side-effect! For example, if f printed its argument to standard output, then our refactoring would have altered the way the program runs.
Thankfully, in our context, we are guaranteed that this is not the case, so we can go right ahead.
fiilterI am going to demonstrate a refactoring of fiilter at every intermediate step. Some people skip these steps when they do this for themselves, but I will specify each step that I usually see. The first step in refactoring the pattern-matching solution is to use foldRight as has already been given:
fiilter p x = foldRight (\a b -> if p a then a:b else b) [] xOnce we get to this step (or perhaps we started here), we move on to removing the repetition in the lambda expression – specifically, the application to the value b appearing on each branch of the if.
First, let’s introduce the id function, perhaps the easiest function to understand ever!
id :: a -> a
id a = aThat’s right, the id function takes one argument and simply returns it. That means I can refactor the above code to this, without changing the way the function behaves:
fiilter p x = foldRight (\a b -> if p a then a:b else id b) [] xAll I have done here is use id on one side of the if branch. Next I am going to do a purely syntactic transformation. I am going to move the use of (:) into prefix position. I am doing this to help make the next step a bit more obvious :)
fiilter p x = foldRight (\a b -> if p a then (:) a b else id b) [] xNow we apply the true side to b using (:) a and the false side using id. We can refactor that away by returning a function on each branch, then applying that result to b:
fiilter p x = foldRight (\a b -> (if p a then ((:) a) else id) b) [] xGreat! The application to the value b occurs only once. Next we can remove the explicit value b that is declared for the lambda expression, then we merely apply a function to it. Let’s just return that function! In other words, since this:
\x -> f x…can be replaced with this:
f…and this:
\x y -> f x y…can be replaced with this:
\x -> f x…then this:
fiilter p x = foldRight (\a b -> (if p a then ((:) a) else id) b) [] x…can be replaced with:
fiilter p = foldRight (\a -> if p a then ((:) a) else id) []OK, this is great! We are simply replacing each cons cell with the given function2 and we needn’t specify the list in the argument list only to apply to it on the far right. But are we finished?
Unfortunately, Haskell (and most languages) provide if as syntax. Since Haskell is a non-strict language, we can easily write it ourselves as a library function:
if' :: Bool -> x -> x -> x
if' p t f = if p then t else fSo how does our code look?
fiilter p = foldRight (\a -> if' (p a) ((:) a) id) []No real improvement.
However, for consistency with other catamorphisms3 in the Haskell library, we should shuffle the argument order4. I will also move the false branching argument to the first position. There is an underlying theoretical reason for this, but run with me for now!
if' :: x -> x -> Bool -> x
if' f t p = if p then t else fGreat, we have a branching function with arguments in appropriate order :)
OK so what about now?
fiilter p = foldRight (\a -> if' id ((:) a) (p a)) []Still no real difference :( However, there is a very regular pattern to be observed here, perhaps a little too advanced for day one, but it is here nonetheless!
Let’s first do a small refactor on our expression using function composition. Any expression of the form:
\x -> f (g x)can be written using function composition:
f . gTherefore, our expression \a -> if' id ((:) a) (p a) can be written:
\a -> ((if' id . (:)) a) (p a)Although, this is a somewhat messy step, it allows us to get to the next one, where the purpose becomes a bit more apparent.
We have an expression of this form:
\x -> f x (g x)This is known as the S combinator of the SK(I) combinator calculus5. The S combinator generalises to an applicative functor6 and we can exploit this to take our refactoring further. The S combinator (generalised) in Haskell is written with (<*>)7 and you will need to import Control.Applicative to use it.
The expression \x -> f x (g x) can be written f <*> g and we have an expression of precisely this form:
\a -> ((if' id . (:)) a) (p a)which can be refactored to:
if' id . (:) <*> pThis is great! So now our solution for fiilter looks like this:
fiilter p = foldRight (if' id . (:) <*> p) []This is how I might express a final solution. Taking the refactoring this far is questionable to begin with, however, it is at least a great exercise in the application of equational reasoning and pattern recognition.
The readability of this code might also be questioned, however, it is very important to properly follow the process of pattern recognition before developing opinions about readability. I usually cannot address this concern quickly or in a helpful way. so I smile at this point and move on to the next exercise. Let’s do that :)
The function names have been altered to prevent clashing with those built-in.↩
I emphasise and develop a very specific intuition of foldRight (and foldLeft) before attempting this exercise, so I be sure to use terminology that is specific to this explanation.↩
foldRight, either, maybe are all functions on which the final argument is the structure that is being folded. There is a very good reason for this, but let’s get on with it!↩
Since if is the fold (catamorphism) for the Bool structure, we will move the Bool to the final argument position.↩
Note the definition on the wiki, Sxyz = xz(yz) or in haskell syntax, s x y z = x z (y z).↩
The ((->) t) applicative functor is the S combinator.↩
I am often asked if this has a pronunciation and although I don’t know of an agreed term, I have heard: “spaceship operator”, “starship operator”, “angle bum.”↩
Here is how you find thinking people.
You give them a really good answer to a problem they are having, spend some effort on it, have it reviewed, etc…
…then insert the word “fuck.”
If they talk about the word fuck, they are losers.
If they continue on learning, they are winners.
Discard losers.
Try to turn the thinking people into really good winners…
…then steal their good ideas.
The losers were never going to give you good ideas anyway.
SIP-18 is a bad idea because it makes awful assumptions about what is in the interest of language newcomers. I have had no shortage of unsolicited advice of how to teach, most of it in layers of wrongness, so I am acutely aware of the sheer quantity of this kind of advice. Please refrain for now. This is only my opinion, because it has been asked of me more than twice.
SIP-18 (and the Scala collections library for that matter) is no different to Haskell’s (dreaded) monomorphism restriction (DMR). The DMR was introduced specifically because of another chronically bold over-estimate of one’s ability to understand the process of learning. It is now an undesired language issue that hinders all users, especially newcomers. In other words, it serves nobody’s interest, hinders everyone’s interest and especially, the interest of those for whom it was meant to serve. You need only spend a short period of time with newcomers to Haskell to be overwhelmed by the prominence of this fact.
I can hear the pragmatists in the background muttering something about trade-offs, not being so extreme and keeping it relevant to the real world and blah blah blah, insert the usual pragmatist bullshit here. There is nothing to be traded off when you offer to take $5 from me for the low cost of $10. Now stop it and get your head out of the clouds so I can talk to you sensibly.
Not only does SIP-18 not help newcomers at all, it helps nobody, hinders everybody and especially newcomers. It is not a trade-off, it is not a good idea; it is simply a bold, severely misguided assertion about how learning takes place – it’s not even an approximation. I have seen only scant pseudo-psychology to support its existence, which obviates its predictable failure.
Hopefully, the Scala guys will work this out, but if Scala’s remarkable precision to repeat historical mistakes is anything to go by, I do not hold high hopes.
Thanks for asking.
L4/L5/S1 fusion performed 15 March 2011
Sacro-iliac fusion performed 01 November 2011
I often hear people complain to me that they cannot use some superior programming language in their environment. Is it the right programming language to use? You sure? Great, now toughen up and use it.
You’re being told that you cannot? What is the reason given? Because “blah blah fucking said so blah blah.” There’s your problem – you subscribe to the illusion of authority and attribute it to the claimant. Abandon the illusion. No; actually abandon it to the extent of total non-existence. “Yeah but blah blah blah…” – I totally didn’t hear what you just said, intentionally. The consequences are not what you think they are.
“Oh but how come you get to use Haskell in your job?” Because I refuse to be bullied by fools proclaiming their authority with disregard for the common goal of getting the job done. Don’t give them the leverage – by way of believing it even exists – it doesn’t. I use whatever is appropriate and Haskell is often appropriate. It’s as simple as that.
HTFU and just do it properly. Unicorns do not exist. Deal with it accordingly. HTH.
01 September 2011
Data Parallelism in Haskell from Rob Manthey on Vimeo.
A follow-on from Lifting. A port of the Scala code to Haskell follows.
class Lift f where
lift0 ::
a -> f a
lift1 ::
(a -> b) -> f a -> f b
lift1 =
ap . lift0
lift2 ::
(a -> b -> c) -> f a -> f b -> f c
lift2 f =
ap . lift1 f
lift3 ::
(a -> b -> c -> d) -> f a -> f b -> f c -> f d
lift3 f a =
ap . lift2 f a
ap ::
f (a -> b) -> f a -> f b
-- scala.List
instance Lift [] where
lift0 =
error "todo"
ap =
error "todo"
-- scala.Option
instance Lift Maybe where
lift0 =
error "todo"
ap =
error "todo"
-- scala.Either[R, _]
instance Lift (Either r) where
lift0 =
error "todo"
ap =
error "todo"
-- scala.Functior1[R, _]
instance Lift ((->) r) where
lift0 =
error "todo"
ap =
error "todo"Java 7 has proposed syntax for what Scala calls two methods:
1. Option.flatMap In Scala where we would normally write:
(a, b, c, d) => for {
aa <- a(argsa)
bb <- b(argsb)
cc <- c(argsc)
dd <- d(argsd)
} yield f(aa, bb, cc, dd)While in Java we write:
// ceremony in the absence of closures
// has been omitted (and altered slightly) for brevity
a(argsa)?.b(argsb)?.c(argsc)?.d(argsd).f();This syntax denotes the bind operation of Option monad, while Scala’s for-comprehension works for any monad. A pedantic point of note is that, from a particular perspective, Java’s syntax is slightly weaker than monad syntax, in that it is in fact, an applicative functor comprehension (not monad), since subsequent computations do not have access to previously computed values along the chain (if this is confuzzling, never mind – it’s important point otherwise, but not so much here). Scala’s for-comprehensions allow this, but it hasn’t been demonstrated above.
Option.getOrElseJava calls this ?:, so while in Scala we might write value getOrElse k, or if you prefer Scalaz, value | k, in Java we’d write value ?: k. The Java version maintains the usual lack of safety of null, while Scala uses an algebraic data type.
Among many differences between Scala and Java here, one is that Scala does not introduce syntax for these two specific functions – after all, why would you? Further, what about the zillions of other useful functions? Java has no user-defined call-by-need unification, which means it is not possible to write ?: yourself (even with a different valid Java identifier as a name). I wrote about this once before. I expect this is the reason for introduction of syntax for representing individual functions.
Scala’s representation is also safer, in that it uses a data structure to denote a list with a maximum length of one, rather than a value with type T, oh wait, just kidding, it might be null!
My favourite part of Java’s proposed introduction of syntax for two very specific functions (among hundreds of others), watered down to be not-quite-as-useful, is the assurance that I am still going to hear about how Scala is complex, while Java is not. Fun times.
Edit: Proposed Java syntax.
Below is a compileable Scala source file. If you read it from top to bottom, it may help with some insights regarding applicative functors. It was partially inspired by Eric’s rendition of The Essence of the Iterator Pattern.
trait Lift[F[_]] {
// Spot the pattern in these type signatures
// of increasing arity.
def lift0[A]:
A => F[A]
def lift1[A, B]:
(A => B) => (F[A] => F[B])
def lift2[A, B, C]:
(A => B => C) => (F[A] => F[B] => F[C])
def lift3[A, B, C, D]:
(A => B => C => D) => (F[A] => F[B] => F[C] => F[D])
// ... and so on
// The relationship between lift<n> and lift<n-1>
// can be given by a function,
def ap[A, B]:
F[A => B] => (F[A] => F[B])
}
trait LiftImpl[F[_]] extends Lift[F] {
// Each lift function uses
// the previous lift function and ap.
def lift1[A, B]:
(A => B) => (F[A] => F[B])
= ap compose lift0
def lift2[A, B, C]:
(A => B => C) => (F[A] => F[B] => F[C])
= f => ap compose lift1(f)
def lift3[A, B, C, D]:
(A => B => C => D) => (F[A] => F[B] => F[C] => F[D])
= f => a => ap compose lift2(f)(a)
}
// Notes
// * lift0 is often called: unit, return, pure, point, η
// * lift1 is often called: fmap, map, ∘
// * lift<n> is often called: liftA<n>, liftM<n>All that is left to do is to implement the LiftImpl trait! You can do this by implementing the ap and lift0 functions.
Examples of implementations that I know will work out if you try to implement them:
class ListLift extends LiftImpl[List]
class OptionLift extends LiftImpl[Option]
class EitherLift[R] extends LiftImpl[({type λ[α] = Either[R, α]})#λ]
class Function1Lift[R] extends LiftImpl[({type λ[α] = R => α})#λ]
Those last couple are a bit funky, but a lot of that is syntax noise rather than anything too complicated. Fill out the body of those classes!
The result of:
The purchase and consumption of 31 medical text books on lower limb orthopaedics, neurology, neuro and spinal surgery and radiology.
Uncountable subscriptions to medical journals.
18 MRIs, 4 CAT scans, 3 XRAY scans, 3 bone scans.
12 surgical procedures; 8 to the lower limb, 3 to the lumbar spine. 1 (successfully) minor procedure performed by myself for a medical emergency for which acknowledgement was initially refused and later accepted after surgical extraction of foreign body.
29 doctors
AU$130K (total estimated)
Having been misdiagnosed by a not-so-clever person named Dr Leigh Atkinson, including the suggestion that my chronic pain is “caused by the holy ghost.” Yes, seriously, he said this – while also in the room with a qualified medical professional (whom he called delusional in the same rant). He also claimed that I did not have Entrapment Neuropathy of SPN when I told him I strongly suspected it. I did – surgically verified by lower limb orthopaedic specialist (November 2009).
Having been repeatedly told for nearly two years by Dr Michael McEniery, who would threaten to sue me again if I was to call him incompetent or dangerous (even though this might be my genuinely held opinion based on substantiated fact and so he would lose) that I am obsessing about a minor condition, requiring no medical intervention, and that this obsession is because of the athletic demands of myself and my coach.
Having executed a partially-successful mission to demand immediate medical attention in March 2009 at significant expense.
I have successfully and single-handedly diagnosed:
Entrapment Neuropathy of the Superficial Peroneal Nerve, 10cm proximal to lateral malleolus (unilateral).
Foraminal Stenosis of the Fifth Lumbar (L5) Nerve Root (unilateral).
Spinal instability (Spondylolisthesis) at Fifth Lumbar (L5).
Withdrawal from morphine and oxycodone after immediate cessation.
These conditions were caused by a single acute sporting injury in July 2007. I have been treated for all.
L4,L5,S1 fusion 15 March 2011 
PS: This is why I sometimes demonstrate low tolerance for stupidity and/or failure or refusal to entertain the possibility of thinking. People get hurt. No, I am not sorry.
This post also incidentally attempts to justify my answer to a question that I regularly encounter, what is your favourite programming language?
It’s not possible to write bug-free programs.
This particular myth is quite popular, and its recent inclusion in a discussion I had has prompted me to write this post. The profound fact of this matter is that this statement is “as false as you can get.” In other words, there exists a formal proof of its negation, and subsequent counter-examples. It has also been my experience that belief in this myth has degenerative practical implications.
To emphasise the point, there exist programming languages for which it is impossible to write an incorrect program. What does it mean for a program to be correct? It means the program terminates. Such languages include (in order of my decreasing experience with them): Coq, Agda, Epigram, Isabelle.
Some people like to think “correctness” includes the thoughts of one or more persons in order to make the assessment. For example, one might proclaim, “sure you have a proof of program termination, but that is not the program that I asked for!” I think this is a poor use of the term “correctness” and I am not considering it any further here.
There is a problem with the aforementioned programming languages. A big one. While you always have correct programs in these languages, you cannot have all general programs. This is a well-documented contention. So you might say that these languages set out to achieve the objective of emphasising correctness, but at the expense of generality – in other words, they are exploring the question: “just how general and practical can we get, without sacrificing absolute correctness?” In my opinion, this is a very important question and worthy of further research.
Other programming languages sacrifice correctness for generality. In my typical work (I work for a product company), this includes languages such as Haskell, Scala and even Scala’s type system (which can be used as an embedded language). I expect most of my readers fall into this category of usage of languages. That is, we are all using languages that explore the question: “just how correct and practical can we get, without sacrificing generality?” In my opinion, this is a very important question too.
In the pursuit of answering both of the above questions, there are a number of contentions that arise. This means that there is not a holy grail programming language. It also means that there is a lot to understand before even starting to talk about the merits of correctness (aka static typing). This is unfortunate given the strong compulsion for, and quality of, popular commentary – we spend too much time clearing up myths. I digress.
However, this issue of contentions and trade-offs does not preclude the existence of questions of dismissal of programming languages. That is, it is possible to ask, and even answer, the question of whether or not there are programming languages that offer nothing toward resolving all of these (meaningful) contentions with respect to peer programming languages. These programming languages may be dismissed as offering nothing toward the goals of computability. It may be said that they are “universally impractical” with respect to the goals of computability (I am explicitly distinguishing here from social objectives). This may seem pessimistic, but it’s just a fact of the matter.
I hope that helps.
I see this a lot, especially in programming forums.
Using the word simple, natural, pragmatic, real world or intuitive to mean “I am able to understand this.”
Conversely, using the word complex, unnatural, academic, “your world” or unintuitive to mean “I am not able nor am I willing to invest the effort to come to understand this.”
If someone does this, I will politely request that it stops, since it crushes any potential useful discussion.
–By request from Viktor. You don’t wanna mess with Viktor.
…and how a marriage to a particular programming language is only indirectly and barely relevant
I was really tempted to title this post, “What to Solve Before Expecting Me to Take Your Opinions of Static Typing Seriously”, however, I figured this would be a bit too controversial and might detract from the points I wish to make. Nevertheless, I just want to make note, I think it is a very appropriate title.
The reason I think it’s a very appropriate title, is because of certain events that have happened recently. I teach advanced programming techniques to programmers. I do this voluntarily for the most part, and I occasionally deliver guest lectures to universities and other sporadic occurrences. I also teach at my place of employment, where I use these techniques for product development. I used to do university lecturing, until I came to the conclusion that the tertiary institution is in direct contention with the goal of education; the latter of which is important to me.
I have constructed the course material myself, predicting what would be useful, too difficult or too easy and so on and revising over time as these predictions fell out of place. Recently I set a task, predicted how difficult it would be, then was astonished to find that it appears to be significantly more difficult than I had originally predicted. I’m still not sure what is going on here, however, I think there are some lessons to be taken. One of which is a lesson about approaches to teaching advanced concepts of programming – something I am constantly learning about (and yearning for more solid research and experimental results!).
I asked students to write an API for the game tic-tac-toe. No need for the computer to tactically play tic-tac-toe – just an API that you can use to model the game itself. You can use any programming language you like, however, I think you will find certain environments to be lacking in the available tools, so I will guide you so that you’re not off somewhere “shaving yaks” so to speak.
If I’d left the requirement there, I can predict what I would have ended up with. Probably something similar to the API that I used to support at L3 for IBM where the number of bugs coming in was at a rate faster than I could fix them – and we don’t want that. Worse still, every time I fixed one bug gave rise to several new ones, no matter what I did! The whole point of this exercise is to avoid this scenario, once and for all, and without all that nonsense that gives false promise to deliver on this objective (Agile, XP, Scrum and all that silliness).
So I set some rules, but without further explanation of why these rules existed:
If you write a function, I must be able to call it with the same arguments and always get the same results, forever.
If I, as a client of your API, call one of your functions, I should always get a sensible result. Not null or an exception or other backdoors that cause the death of millions of kittens worldwide.
If I call move on a tic-tac-toe board, but the game has finished, I should get a compile-time type-error. In other words, calling move on inappropriate game states (i.e. move doesn’t make sense) is disallowed by the types.
If I call takeMoveBack on a tic-tac-toe board, but no moves have yet been made, I get a compile-time type-error.
If I call whoWonOrDraw on a tic-tac-toe board, but the game hasn’t yet finished, I get a compile-time type-error.
I should be able to call various functions on a game board that is in any state of play e.g. isPositionOccupied works for in-play and completed games.
It is not possible to play out of turn.
Now, why these rules? Well, because if you can achieve the goal of enforcing these rules, then the next phone call that I get in L3 support from an upset client, I can be guaranteed that one of the following are true:
I have a bug in my code, in which case, the sooner the call, the better! …unless of course, fixing the bug results in only more bugs – but we have avoided that possibility – hopefully you can see why.
The client has misused the API and circumvented the type system. The client has used null, thrown an exception or performed a side-effect within the API or perhaps even used such things as Java reflection or even type-casting or type-casing. Unfortunately, in some environments, there’s not much I can do about enforcing that except impose a de facto rule where you assume non-existence of these possibilities (Just don’t do that!). Hopefully you haven’t yet jumped to the conclusion that any of these things are necessary or even useful – they aren’t.
The client is simply mistaken about the merits of their complaint.
That’s it. There is nothing more to add to the list. Importantly, this list is significantly shorter than the list that I once had when supporting a typical Java application in IBM L3 support. How did I achieve this narrow list of possibilities before the phone even rang?
I have actually solved this problem using various programming languages:
Haskell
Scala
C#
Java
In order to take the emphasis off programming-language-centric issues, I will focus now on the Java solution (the most challenging environment in which to achieve the goal) and then I am going to invite you to conduct a thought experiment.
Let’s take a look at the javadoc for the Java solution. Ignore the Main class for now, which simply gives you a 2-player console application that uses the API (feel free to run it!) – it depends on the rest of the API and so could be deleted without breaking anything.
If I asked you to be the most malicious user you can be, so long as you followed the rules (which I will assume you have done from here on), I want you to get an instance of the FinishedBoard class. If you rang me up in L3 support, even hiding your malicious intent from me, and said you had such an instance, then I am absolutely guaranteed that you obtained that instance by playing a legitimate game of tic-tac-toe and ended up with a game that is in the position of a player winning or a draw. Consider the implications of this for a moment.
For another example, suppose you rang and said that you called the move function and when you ran it, something-or-rather happened at run-time, I can be guaranteed that you called that function on a game that was in-play and so had the ability to move, since otherwise it would not have compiled, let alone run.
There are many more examples of these types of guarantees – invariants that I am certain have been met before I even start listening to you on the phone. I think this is an enormous advantage to real-world software tasks, don’t you? And all this done with Java and its overwhelmingly impractical type system. How about that!?
Now, producing an API of this nature seems to be more difficult for programmers than I originally predicted. Why is this? I can only conjecture and given my already-disproportionate prediction, I am hesitant to do so. Nevertheless, what you are looking at is an extremely robust API for a relatively trivial problem. This API robustness was achieved by exploiting techniques available from static typing and functional programming.
So let’s summarise. A robust API for a trivial game was written using several programming languages in such a way that appears to be difficult for many programmers to reproduce and using techniques such as exploiting static typing and functional programming. This was even done with a popular programming language that is not particularly amenable to achieving this degree of robustness.
In other words, many programmers have difficulty solving a trivial problem using techniques that many programmers are compelled to offer their comment on – no wonder there is a lot of outrageous hype! On the topic of why I expect you to be able to solve this problem before I take you seriously – it’s not because I have high standards, they’re incredibly low – it’s just that while these standards are very low, they are rarely satisfied. This is not a high-horse-motivated rant (as many insecure people might hastily conclude), the point I am making here is that I think it’s important to set standards of scepticism – maybe you should too!
It’s not just support issues where you will see an advantage to this programming technique. You might be writing an API for the guy sitting next to you. Those types are machine-checked documentation – he won’t have to keep bothering you about which function to call when – it’s obvious, since it’s specified in the type! You might even be your own client – suppose you hit a bug in your own code – you can rule out a huge number of possibilities of where that bug is, before you even start looking for it.
All these advantages of robust API design for less expense than the contrary and yet robust API design seems to be overwhelmingly rare. I am left only with questions, aren’t you? Come on guys, we can do a whole lot better. It’s an invitation!
It’s possible to take this particular API problem further using a language such as Agda or Coq and enforce the invariant that it’s not possible to make a move to a position on a board if that position has already been moved to. I know of one person who is attempting to achieve this. Godspeed.
I haven’t shown you the source to any of these solutions because I figure you might want to take a crack at it yourself. Give it a go! If you really want the source let me know and I’ll send you a link.
Hopefully this helps!
On the Scala mailing list, I said “monads do not compose.” What does this mean exactly? Hopefully the following answers it.
Let us first state the Functor, Applicative and Monad interfaces:
trait Functor[F[_]] {
def fmap[A, B](f: A => B, a: F[A]): F[B]
}
trait Applicative[F[_]] extends Functor[F] {
def ap[A, B](f: F[A => B], a: F[A]): F[B]
def point[A](a: A): F[A]
override final def fmap[A, B](f: A => B, a: F[A]) =
ap(point(f), a)
}
trait Monad[F[_]] extends Applicative[F] {
def flatMap[A, B](f: A => F[B], a: F[A]): F[B]
override final def ap[A, B](f: F[A => B], a: F[A]) =
flatMap((ff: A => B) => fmap((aa: A) => ff(aa), a), f)
}Let’s now restate our claims:
Functors compose
Applicatives compose
Monads do not compose
I will now address points 1) and 2). What does it mean for X to compose in this context? Let us now answer that question more succinctly:
It means that we can write a function with this signature (for some X):
def XCompose[M[_], N[_]](implicit mx: X[M], nx: X[N]):
X[({type λ[α]=M[N[α]]})#λ]This return type may look like gobbledy, but it’s just a fancy way of doing partial type constructor application in Scala. It is essentially the X type constructor applied to the composition of M and N and followed by a type variable just like M and N itself (kind * -> *). Let us now test our claims.
Functors compose. That is to say, we can write:
def FunctorCompose[M[_], N[_]]
(implicit mx: Functor[M], nx: Functor[N]):
Functor[({type λ[α]=M[N[α]]})#λ]Let’s do it!
new Functor[({type λ[α]=M[N[α]]})#λ] {
def fmap[A, B](f: A => B, a: M[N[A]]) =
mx.fmap((na: N[A]) => nx.fmap(f, na), a)
}Here we are composing two Functors. Claim 1) is demonstrated. What about claim 2)? Here we go. Hold your breath!
def ApplicativeCompose[M[_], N[_]]
(implicit ma: Applicative[M], na: Applicative[N]):
Applicative[({type λ[α]=M[N[α]]})#λ] =
new Applicative[({type λ[α]=M[N[α]]})#λ] {
def ap[A, B](f: M[N[A => B]], a: M[N[A]]) = {
def liftA2[X, Y, Z](f: X => Y => Z, a: M[X], b: M[Y]): M[Z] =
ma.ap(ma.fmap(f, a), b)
liftA2((ff: N[A => B]) => (aa: N[A]) => na.ap(ff, aa), f, a)
}
def point[A](a: A) =
ma point (na point a)
}Have fun untangling that! It’s a bit noisy but this is mostly because Scala requires a lot of boilerplate. Hopefully you can get to the essence of what it means to compose two Applicative functors.
Now let’s move to Monad. Essentially, I am saying that you won’t be able to write such a function for Monad. I really encourage you to try to write it so you can see the twist that you will get into.
def MonadCompose[M[_], N[_]](implicit ma: Monad[M], na: Monad[N]):
Monad[({type λ[α]=M[N[α]]})#λ]Here is a compilable version http://paste.pocoo.org/show/343606/
Hope that helps!
A pseudo difference list with constant time prepend (cons) and append (snoc).
There is an efficiency issue with respect to Scala’s TCO implementation (making this data structure untenable?), however, I have forgotten the details of that.
In any case, a finger-tree is often more appropriate, but it would be nice to revive the Endo[List[A]]!
sealed trait DiffList[A] {
val endo: List[A] => List[A]
import DiffList._
// cons O(1)
def <::(a: A): DiffList[A] = new DiffList[A] {
val endo = (z: List[A]) => a :: DiffList.this.endo(z)
}
// snoc O(1)
def ::>(a: A): DiffList[A] = new DiffList[A] {
val endo = (z: List[A]) => DiffList.this.endo(a :: z)
}
// append O(1)
def :::>(a: DiffList[A]): DiffList[A] = new DiffList[A] {
val endo = (z: List[A]) => DiffList.this.endo(a.endo(z))
}
// O(n)
def toList = endo(Nil)
}
object DiffList {
def empty[A]: DiffList[A] = new DiffList[A] {
val endo = (z: List[A]) => z
}
def single[A](a: A): DiffList[A] = a <:: empty[A]
}…of a whinging cunt with nothing useful to say. How fucking sad. At least try, at least, for fuck’s sake.
Martin Odersky, creator of the Scala programming language, recently wrote a brief article describing levels of Scala expertise. Martin labelled the levels in increasing order: [A1, A2, A3, L1, L2, L3].
I wish to register a small objection here, with recognition of otherwise sound judgement. While the objection is small, I think the consequences of what I believe is an error, are quite detrimental.
I will repost Martin’s specification for L3, the highest:
Level L3: Expert library designer
- Early initializers
- Abstract types
- Implicit definitions
- Higher-kinded types
First, I will get a couple of nitpicks out of the way. Martin’s L2 specifies that variance annotations will be used at this level. I (we: scalaz) propose that there is another level again, where you come to the realisation that variance annotations are not worth their use in the context of Scala’s limited type-inferencing abilities and other details. Instead, prefer a short-hand version of fmap and contramap functions. Scalaz calls these ∘ and ∙. The details of why this is more appropriate are beside the point here. Nevertheless, Edward Kmett has set out to prove this hypothesis wrong. Many of us have and failed. As far as I know, there is nothing compelling yet but I wish Ed luck with his unique insights.
Second, the suggestion that L3 requires the use of early initializers boggles my mind a little. The idea that these details exist at all is a symptom of a lot of nasty language and interoperability issues. Ultimately, if you are relying on the language-specified initialization order in your library code, then you are doing something disastrously wrong. Long-time users of Scala will recall the number of changes this behaviour went through. There is a gremlin at every turn and (much) more disciplined approaches to library design.
To the point.
If L3 is the highest level attainable, where we are using higher-kinded values and implicits, then what about other levels that are way higher in the level of required understanding? Let’s be clear, the use of these features has been part of Scalaz for a few years now. I started Scalaz in 2007, when I learned that Scala had these two features (which are extremely important to library design). These features have enabled the encoding of much more advanced concepts – what about those?
Some concepts that belong way higher than Martin’s L3 specification are:
encoding type-level transformations
advanced purely-functional data structures
automated specification-based testing and associated library authoring requirements to effectively achieve it
encoding algebraic structures of category theory and ensuring these are available for practical use
understanding type theory, its goals and (truly understanding, for real) the benefits and trade-offs of static program verification
attempting a high (read: extremely high) degree of abstraction in the context of Scala’s limited laziness abilities.
I take issue here because keen learners may be fooled into believing that as they are confident in understanding all concepts at L3, then they are qualified to be an “expert library designer.” I put it to you that there is an extraordinary leap from L3 to an API designer of any considerable merit. Indeed, in my opinion, L3 is just enough knowledge to even begin practical library design. Before I attract a charge of shooting too high or the usual anti-intellectual nonsense, I like to remind others that I like to aim high, very high. I encourage you to do so too. Nothing more.
I recently gave a beginner API design quiz. I use it in programming classes that I teach, where many people struggle with it. When these students eventually break through, they are equipped with a reasonable fundamental understanding of writing practical libraries and APIs. However, note the triviality of the problem and the observation (if you’ll trust me), that many programmers have difficulty. This leaves open a huge opportunity for improvement in problem-solving skills – let’s take it!
I’d hate to believe that L3 is “expert.” I’d be saddened to think others have been tricked into settling there too. Surely we can shoot higher than that Martin.
A case in point, I was directed to this comment:
If it [scala] is a failure, why has the language - for exaple [sic] - the best collection library of all languages currently out there?
Honestly and without any intention to exaggerate, it boggles my mind with fascination as to what could cause such a rapid and extreme departure from reality. Working with both Scala and Haskell in depth for many years, there is nothing more disheartening than putting Haskell aside and dealing with the underwhelming practicalities of Scala’s (and therefore, Java’s) libraries. Indeed, this Great Big Hole That Is Still Gaping Wide was one of the primary motivations for the creation of Scalaz when I was working on a commercial application yearning for useful libraries. That was many years ago. Nothing has changed.
That’s just Haskell. There are other examples of programming environments that completely annihilate Scala/Java in terms of useful libraries.
To believe the aforementioned statement is perhaps a symptom of shooting so disastrously low as purported by “L3, the highest level of expertise.” In other words, there are serious and observable consequences for having such low standards, to such an extent that one may even fall under the illusion presented in this statement. I hope you’ll agree that there are practical implications for believing these things.
Then I witnessed this comment, which completely misses the point. Specifically, this commenter is not at what Odersky would call L3, since the comment demonstrates lack of understanding of higher-order polymorphism (aka higher-kinds). I don’t wish to pull apart every naive comment, but I do wish to point out that we can aim much higher than this.
MUCH MUCH HIGHER
I lament, but fight on, for the encouragement of setting a higher standard. Sorry guys, but you’re way off base. We can do a fuck-load better than this and we have done exactly that, elsewhere.
– a former contributor to the Scala collection libraries with high hopes
I went looking for my grandmother today, who lives on the bank of the Brisbane River in Wivenhoe Pocket. I didn’t find her, but I’ve been assured she is safe.
* Video
Fernvale bridge 32 hours after peaking during major flood. The edge of the water is 830 metres from the bridge which is typically used to traverse the river. The width of the river is estimated to be over 1.5km.
The dried mud on the bitumen road indicates the peak height that was reached.
Note the street sign indicating a side street ahead. Coominya State School lies completely submerged in the water ahead.
Map location The marker denotes the edge of the water as seen in the video to within a few metres.
* Video
Alice Street and Queen Street, Goodna, Brisbane 32 hours after Brisbane River peaks in major flood disaster.
The peak height of the river can be seen at 0:01 when the road changes to a dirty colour.
* Video
Schmidt Road, Fernvale 32 hours after Brisbane River peaks in major flood disaster.
The peak height of the river can be seen in the debris that hangs in the fences.
I was linked to this silly thread today. I didn’t read much of it and I recommend you don’t either.
Instead, take note, it’s yet another example of Java programmers knowing one language and knowing it poorly. This consistent observation is not particularly interesting, but this particular misunderstanding was cleared up years ago. I went through an old Java FAQ database that I had written while I was working on the IBM implementation in 2000 where I explained all this. It was even asked in one of my wanky Java certifications back then. There were surely other explanations around at the time too. Sigh, Java guys, please… do yourself a favour and at least understand the shitty language that you hold so dear.
Java has two possible parameter types
Object references
primitives (restricted to 8 in total)
Note here that Java never passes objects, ever. They do not appear in the list above, double-check to make sure. Now, you don’t have to take my word for it; after all, I’m just a former implementer of the language and API specification and I assure you, that doesn’t change a thing with regard to credibility. However, just what was I implementing back then? It was a number of specifications; one of which was called The Java Virtual Machine Specification (VMS).
Here is section 2.10.1 of the VMS. I will quote the whole section to make sure this point sinks in. If you are unsure whether Java passes by reference or value or some variation, then please read it again. Repeat this until you comprehend the important part. Here goes:
The formal parameters of a method, if any, are specified by a list of comma-separated parameter specifiers. Each parameter specifier consists of a type and an identifier that specifies the name of the parameter. When the method is invoked, the values of the actual argument expressions initialize newly created parameter variables (§2.5), each of the declared type, before execution of the body of the method.
A method parameter of type float always contains an element of the float value set (§2.4.3); similarly, a method parameter of type double always contains an element of the double value set. It is not permitted for a method parameter of type float to contain an element of the float-extended-exponent value set that is not also an element of the float value set, nor for a method parameter of type double to contain an element of the double-extended-exponent value set that is not also an element of the double value set.
Where an actual argument expression corresponding to a parameter variable is not FP-strict (§2.18), evaluation of that actual argument expression is permitted to use values drawn from the appropriate extended-exponent value sets. Prior to being stored in the parameter variable, the result of such an expression is mapped to the nearest value in the corresponding standard value set by method invocation conversion (§2.6.8).
Let me extract a really important part:
_…initialize newly created parameter variables (§2.5), each of the declared type, before execution of the body of the method. _
Did you see that? Java is pass by value, without reservation. It says so in the specification. It is even observable by writing a trivial program.
Object o = new Object();Now I know you may be accustomed to calling ‘o’ an object here, and it may even be the source of confusion, but it’s not an object. It’s an object reference. The object referred to by ‘o’ has no name.
When you pass ‘o’, it is copied, as per the specification, to a new reference, specified by the method being called. This means that if you reassign that reference, it cannot be observed outside of that method. Of course, since it is a copy of the method parameter.
void method(Object o) {
o = x; // not observable outside local scope
}If you were to dereference ‘o’ you may be able to execute some effect that may be outside of the method. Note the adjective here, dereference. What are we dereferencing? An object reference of course! Surely you have seen a NullPointerException. Know what this means? You dereferenced a reference which held no object!
I don’t know how else to make this clear, so I won’t continue trying.
Java is pass by value.
Write an API for playing tic-tac-toe. There should be no side-effects (or variables), at all, for real. The move function will take a game state, a Position and it will return a data type that you write yourself.
The following functions (at least) must be supported:
move (as mentioned)
whoseTurn (returns which player’s turn it is)
whoWon (returns who won or if a draw)
playerAt (returns which player, if any, is at a given position)
Importantly, the following must be true:
It is a compile-time error to call move or whoseTurn on a game that has been completed
It is a compile-time error to call whoWon on a game that has not been completed
The playerAt function must be supported on both complete and in-play games
Good luck and may the types be with you.
Sometimes I’ll be working away when a colleague will make some distinction between “that which is configuration” and “that which is code.” In all cases, it turns out that this distinction is premised on a having a very narrow understanding of solving software problems. That can’t be good.
When we write compositional code using techniques such as referential transparency, the distinction between configuration and code completely evaporates. I wish to emphasise this evaporation, so I will restate it: it is not possible to determine which is configuration and which is code, except when using very sloppy problem solving habits, no matter how much we wish to save the thesis. I made this emphasis because I have even seen people accept that the delineation disappears, then in the very next breath say something to the effect as if it were still there. Brains are fascinating machines. I digress.
Let us suppose a Haskell program, though, the language is unimportant to this point. We only need to examine the type signature:
application :: IO ()If we need some form of “configuration”, such as a possible String value with a “default”, we pass it as such:
application :: Maybe String -> IO ()Then the body of application will apply the default: fromMaybe "default string". Easy right?
You might have multiple configuration values and not necessarily with the type String. Now of course, since we are using Haskell (and not XML!), we can give our configuration values a type! Here is an example:
data Initialisation = Initialisation {
ioWait :: Int
, performance :: Speed
, password :: String
}then your application becomes:
application :: Initialisation -> IO ()With Haskell you also get record selector syntax with this data structure. This means that setting say, 2 of these values can be done with effort proportional to the size of 2. With languages such as Java, achieving this goal results in a quadratic blow-out, requiring n^2 methods with overloads where n is the number of record fields.
Now, notice how doing this is simply, using a function. Let’s be clear, I am using a function, like any other, a function, code. It is not special and does not deserve any elevated status above other functions. No more useless ceremony here.
A good example of an application, that I use each day, is xmonad, which I “configure” by writing Haskell. OK, now let’s be honest, I just write a program and take advantage of the comprehensive libraries.
In some cases that make the distinction between configuration and code, it’s often that an inappropriate language has been chosen to write code in, such as XML. There is a direct mapping between the XML and whatever programming language they are using. However, the XML will often exhibit properties that programming languages such as Haskell exhibit universally e.g. reordering statements does not affect the observable outcome of the program. In other words, this is just functional programming with XML (yeah, my thoughts exactly).
Any effort that delineates between configuration and code is nothing more than a very reliable indicator of sloppy thinking. Think again.
I once had the following discussion with someone regarding a Java project:
Him: Once we did a project and we didn’t return anything from a method, ever (i.e.
void) It went very well. Me: So everything was in CPS transform then so that you could simulate it? Him: No, we didn’t ever return anything ever! Me: So uh, it was uh, in CPS transform then, since er… you know… Him: No! Nothing. Return. Nothing. Ever. Void. Always! Me: Er yeah right uh huh.
This person operates under the illusion that I am in an intellectual battle with him, so I can excuse the somewhat awkward discussion. My efforts to destroy this destructive illusion have been repeated failure to date. That’s a side-story.
It occurred to me later, thanks to Edward Kmett, that perhaps it wasn’t a CPS transform but using exceptions instead! I doubt that was the case :) I’m also reasonably confident this discussion was argumentum ad ignorantiam – my converser doesn’t know what CPS transform means (so it can’t possibly be true!), but that’s cool – let’s not dwell on it. Instead, let’s have a look how you can simulate returning a value without actually returning a value using continuation-passing style (CPS)!
We may conjure up both simple and elaborate examples of functions that actually return a value:
Integer wibble(String s, double d)
Swizzler function1(int i, String s, Swazzle z)I am going to use the trivial example (top one), but I hope you’ll be able to extrapolate to swizzlier cases.
First, note that Java methods may perform side-effects willy-nilly. Passing in a String and a double are not the only values that the function may access. The function may print to standard output, use variables in any scope, read/write files, the network and so on. This changes things a little (read: a lot) with regard to how we look at a function, so perhaps this is why this technique has apparent (read: apparent) merit.
Suppose a very simple interface:
interface To<a> {
void to(A a);
}Quite simply, this function takes a polymorphic (aka generic) value and performs a side-effect, perhaps using this value. It is important to point out that this polymorphic interface may be modelled differently e.g. it may not be polymorphic:
interface Stringer {
void stringer(String s);
}This interface is exactly equivalent to To<String> so I’m also trusting that you’ll extrapolate my generic example to other possibilities.
Now, instead of returning a type e.g. Integer in the wibble function, we may return void with an additional To<Integer> argument. We can do this for every single function that would otherwise return a value!
How does that work then? Simple really. We compute the Integer as we normally would in the body of wibble and instead of returning it (we can’t of course), we pass it to the to method of the given To<Integer> instance.
void wibble(String s, double d, To<integer> t)And so on it goes, for every method.
Essentially, this results in a function that, instead of returning a value of type T, returns a value of the type (T => void) => void where (T => void) is represented by the To interface and is of course, in the position of a method argument where that method returns void. This is exactly equivalent to a specific example of a continuation. We are doing a CPS transform to simulate returning a value!
To summarise the formula:
For a method that would normally return a type T, we can transform it in such a way to accept an argument of type
To<T>and returns void.
As for the merits of doing this, well I’ll leave that for another battle :) Further, there are some interesting properties about continuations, in particular, they are a monad, perhaps even the mother of all monads, but we’ll leave all that for another day too.
Edit: Per comments, I think a clarification is in order. Doing this is a very very bad idea on the JVM (without tail-call elimination – note that the IBM implementation only does direct TCE). Doing this results in a significant performance degradation and increased syntax for zero benefit. I didn’t bring this up because I was never going to get that far in the original conversation that I mention. Beware.
With idiotic shit like this, followed by overwhelmingly stupid commentary like this and the most ignorant and intellectually under-equipped programmer on the internet (prove me wrong, but not now, in my moment of lament), I have cancelled my reddit account.
Fool is me for not doing it sooner. Bye.
Prompted by a question on the scala mailing list, I have produced below a minimal library representing a data type called Logger and its monad implementation (see the map and flatMap methods).
This data type represents logging in a pure functional environment where you maintain compositionality of your code (i.e. no side-effects) and also, brevity of code – see the example usage below using a for-comprehension demonstrating this.
trait Monoid[A] {
def append(a1: A, a2: A): A
def empty: A
}
object Monoid {
implicit def ListMonoid[A]: Monoid[List[A]] = new Monoid[List[A]] {
def append(a1: List[A], a2: List[A]) = a1 ::: a2
def empty = Nil
}
}
case class Logger[LOG, A](log: LOG, value: A) {
def map[B](f: A => B) =
Logger(log, f(value))
def flatMap[B](f: A => Logger[LOG, B])(implicit m: Monoid[LOG]) = {
val x = f(value)
Logger(m.append(log, x.log), x.value)
}
// insert much more
}
object Logger {
def unital[LOG, A](value: A)(implicit m: Monoid[LOG]) =
Logger(m.empty, value)
// insert much more
}
object Util {
// utility
implicit def ListLogUtil[A](a: A) = new {
def ~>[B](b: B) = Logger(List(a), b)
def <|~[B](k: A => B) = Logger(List(k(a)), a)
}
def noLog[A](a: A) =
Logger.unital[List[String], A](a)
}
// begin example
/*
$ scala Main 456
RESULT: 7000
LOG
---
adding one to 456
converting int to string 457
checking length of 457 for evenness
multiplying 1000 by 7 to produce 7000
*/
object Main {
import Util._
def main(args: Array[String]) {
val x = args(0).toInt // parse int from command line
val r =
for(a <- addOne(x);
b <- intString(a);
c <- lengthIsEven(b);
d <- noLog(hundredOrThousand(c));
e <- times7(d)
) yield e
println("RESULT: " + r.value)
println
println("LOG")
println("---")
r.log foreach println
}
def addOne(n: Int) =
("adding one to " + n) ~> (n + 1)
def intString(n: Int) =
("converting int to string " + n) ~> n.toString
def lengthIsEven(s: String) =
("checking length of " + s + " for evenness") ~> (s.length % 2 == 0)
def hundredOrThousand(b: Boolean) = // no logging
if(b) 100 else 1000
def times7(n: Int) =
(n * 7) <|~ ("multiplying " + n + " by 7 to produce " + _)
}Keeping with the spirit of recent topics, here is a letter I recently received:
08 October 2010
Dear Mr Morris,
DR MICHAEL MCENIERY
We act on behalf of Dr Michael McEniery.
Our client has provided us with a copy of your letter to Dr Lachlan Steffen dated 15 September 2010.
A number of comments within your letter are grossly inappropriate and contain defamatory imputations about our client, suggesting that he is dangerous and incompetent.
The publication of defamatory material in Queensland is actionable under section 7 of The Defamation Act 2005. Please understand that our client takes strong objection to your conduct and reserves his right to claim damages.
Our client demands that you immediately cease making any negative or derogatory comments or publications which may cause injury or loss to him. If you do not cease such conduct our client may take such action as he is advised without further notice to you.
Yours faithfully,
David Watt
…and a response…
29 October 2010
Dear Mr David Watt,
Re: DR MICHAEL MCENIERY (08 October 2010)
No.
Sincerely,
I might just leave this here:
DEFAMATION ACT 2005 - SECT 25
Defence of justification
It is a defence to the publication of defamatory matter if the defendant proves that the defamatory imputations carried by the matter of which the plaintiff complains are substantially true.
…and this too…
DEFAMATION ACT 2005 - SECT 31
Defences of honest opinion
(1) It is a defence to the publication of defamatory matter if the defendant proves that –
(a) the matter was an expression of opinion of the defendant rather than a statement of fact; and
(b) the opinion related to a matter of public interest; and
(c) the opinion is based on proper material. Just sayin’ :)
import java.io.File;
import java.util.Calendar;
import static java.util.Calendar.DAY_OF_WEEK;
import static java.util.Calendar.THURSDAY;
import static java.util.Calendar.TUESDAY;
import static java.util.Calendar.WEDNESDAY;
public class ThreeAdder {
// Convenience method to add the two given numbers, then adds 3.
// It's really convenient, promise.
// It even has tests and they passed! See below.
public static int addThen3(int a, int b) {
if(new File("/etc/passwd").exists() && a < 100) {
return a + b + 3;
} else if (b == 2) {
int day = Calendar.getInstance().get(DAY_OF_WEEK);
if (day == TUESDAY || day == WEDNESDAY || day == THURSDAY)
return 5 + a;
else
return 9;
} else if(a == 0) {
return b + 3;
} else if(b == 0) {
return a + 3;
} else {
return 8;
}
}
public static <a> String assertEq(String name, A x, A y) {
return name + (x.equals(y) ?
" [PASSED]" :
" [FAILED] {" + x + "} {" + y + '}');
}
public static void main(String[] args) {
String[] out = {
assertEq("adding to zero", addThen3(0, 0), 3)
, assertEq("adding to zero", addThen3(0, 4), 7)
, assertEq("adding to zero", addThen3(4, 0), 7)
, assertEq("adding to zero", addThen3(1, 0), 4)
, assertEq("adding to zero", addThen3(0, 1), 4)
, assertEq("adding to zero", addThen3(0, 1), 4)
, assertEq("small numbers", addThen3(2, 4), 9)
, assertEq("small numbers", addThen3(2, 3), 8)
, assertEq("small numbers", addThen3(3, 3), 9)
, assertEq("small numbers", addThen3(3, 2), 8)
};
for(String o : out) {
System.out.println(o);
}
}
}No.
Safari Tanks recently released a long range fuel tank for the Husqvarna TE250/310/450/510 4-stroke enduro motorcycle. These bikes come standard with a 7.2 litre fuel tank, which simply does not cut the mustard, particularly for the thirsty 510.
I own a 2009 TE510 and a few weeks ago, I purchased this tank. I was given the option of four colours: red, white, black or translucent. I chose white and I am happy with this choice. At this time, my bike had only done a few road kilometres and had not yet completed run-in.
Prior to my current TE510, I have owned other Husqvarna four stroke enduro motorcycles, but the TE510 is my first fuel-injected Husky. Below, I will attempt to write a balanced report of my experience with this product. Comments or questions are appreciated.
When it came time to fit the fuel tank, I found that the fuel pump did not install as specified and instead, could only fit in a 180 degree position. This is fine, except the supplied fuel line now did not reach the fuel tap outlet. Safari Tanks were quick to help me with this problem, spending a lot of time on the phone to resolve it (I live in Brisbane, about 1400km from Safari headquarters). Safari supplied me (express postage) with a suitable fuel line for the altered fuel pump fitting after I provided the measurements. This fuel line met my specifications and fit perfectly.
The supplied instructions did not mention that the side radiator guards (not the fins) must be removed, however this was pretty obvious since the tank was not going on otherwise. The fuel tank appears to provide better protection from side impact than the original guards as well. The stock radiator fins did not require any modification at all.
I had trouble fitting the seat since the seat post was a little too far posterior, so I removed the seat post. This allowed the seat to install perfectly.
As for the performance of the tank I cannot speak highly enough. After recently spending a 3-day weekend riding in a massive state forest, I didn’t once come even close to hitting reserve on the 510, nor did I ever fill the tank (to keep weight down). The tank is simply enormous and this attracted comments from other riders, even though it blends well with the bike’s styling.
However, aside from the extra weight of carrying more fuel, the ergonomics of the tank are indistinguishable from the original tank and it allows you to adopt a correct riding position even in aggressive riding. I was quite impressed with this obviously clever design given the massive increase in fuel range. I expect this is because the extra fuel capacity is below the typical fuel tank position.
The (supplied) fittings and mountings for the tank are very strong, particularly for the frame mount, and even after some hard riding (to give you an idea, I wrote off the stock tyre in 15 minutes) there was no sign of fatigue.
After going riding with my mates on a 510 race-style enduro with a 7.2 litre tank, it’s usually me who is the first to complain of the need to return to a fuel supply. Not anymore, not even close. I’m very happy with the purchase of the Safari fuel tank and I would recommend it to anyone. After dealing with some minor fitting issues and the obvious attention given to my complaints, I have no doubt that Safari will have sorted out those issues by now. I would recommend this fuel tank to any fellow enthusiast of Husqvarna high-performance motorcycles.
Some pictures of the bike fitted with the tank follow.
Husqvarna TE510 Safari Fuel Tank
Husqvarna TE510 Safari Fuel Tank
Husqvarna TE510 Safari Fuel Tank
Husqvarna TE510 Safari Fuel Tank
Husqvarna TE510 Safari Fuel Tank
Husqvarna TE510 Safari Fuel Tank
A friend of mine, Brad Clow, has received demands to remove one of his blog posts by a lawyer. This post contains a letter that I wrote to the Medical Health Board of Queensland in March 2009. The letter mentions the name of a doctor, from whom I have also received recent threats of legal action; specifically allegations of defamation. Brad has removed the name of this doctor.
These threats are without any legal basis at all and a cursory read of The Defamation Act 2005 makes this really quite apparent. Specifically, sections 25 and 31. Neither myself nor Brad have made any defamatory claims against Dr Michael McEniery, however, I do have honestly held opinions which are based on facts which are substantially true. These opinions and facts will be made available for public viewing after I have sought advice from legal experts. Advice in this regard is most welcome and I promise a remarkable and quite alarming story.
It took me a little over a year longer to finally determine the correct diagnosis. I had an entrapment neuropathy of the superficial peroneal nerve 10cm proximal to the lateral malleolus causing traction injury and subsequent foraminal stenosis at the right L5 nerve root, resulting in severe neurological deficit. I also had anteromedial osseous impingement syndrome (caused by tibia/talus collision from foot drop) and four improperly installed screws causing (painful) interference in the talar joint. It is now 6 months since surgical resolution and I am left with some neurological deficit. It is not known if I will fully recover, though the treating surgeon is hopeful.
Brad’s original post, before he yielded to the legal demands, follows.
We received a copy of this yesterday evening. Please note Tony is a friend of mine and this is genuine.
To The Medical Board of Queensland,
My complaint is rather lengthy. It relates to an injury and subsequent treatment of that injury by various doctors and surgeons. I am not primarily complaining about any particular individual of the medical institution, rather, that I still have not been diagnosed and treated for my condition. I am desperately seeking diagnosis and a treatment. Some doctors may believe they have diagnosed my condition, but they have been wrong and this has been proven surgically. The best diagnosis available today is my own humble conjecture, which is terrifyingly inadequate.
On 28 July 2007, I suffered a severe inversion sprain to my right ankle. I'd suffered a few previous sprains, but this one was much worse than others. I was kicking a football rather hard when I landed incorrectly. I was not weight-bearing for about 5-6 days. During that time I was a very fit athlete playing A1-grade tournament squash and was very active with many other hobbies.
Over the following months after the injury, I tried returning to sport and I could feel I had something wrong in my ankle. I hoped it would resolve, but it didn't. I could not put my joint into dorsiflexion due to a mechanical impingement and this resulted in muscle atrophy. Subsequently, I became very ill. Nevertheless, I pushed on with my sporting endeavours expecting my body to overcome the problem like it had many others in the past.
Eventually I conceded in January 2008 and sought help from Dr. Michael McEniery. We tried various treatments including a cortico-steroid injection and obtained MRI radiographs. Over time, this condition worsened to the point where I was forced to discontinue sport in May 2008. I have not been active since. I sought help from an orthopaedic surgeon, Dr. Greg Sterling, who prescribed a Broestrom Repair and medial arthroscopy since my complaint was mostly anteromedial.
At the time, I was very medically-illiterate and put much faith in medical doctors. I assumed a positive outcome from surgery, simply because I'd had surgery in the past for various conditions and I was always better afterward. The procedure was performed on 15 September 2008 and the medial arthroscopy revealed deltoid ligament damage which was also repaired along with the ATFL and CFL.
I wore a cast for 2 weeks and an orthodic boot thereafter. Although I was in pretty intense pain, I'd attributed this to the recent surgery and thought it would resolve. It didn't. In October 2008, I knew I was in big trouble – I had similar symptoms to pre-operative but they were now much worse. I immediately sought help from Dr. Greg Sterling who requested another MRI but in November 2008, could see nothing wrong. He said “see you in January 2009”. The prospect of waiting so long in agony was traumatising.
Around the same time, I'd sought help from Dr. McEniery who claimed I was exaggerating my symptoms and attributing too much attention to my condition. This blatant oversight added further to my trauma – and he'd almost convinced a member of my family of these falsehoods. I was suffering psychologically and I sought immediate help from Prince Charles Mental Health Unit.
I was discharged as an outpatient but I knew I was not mentally ill – I was in incredible pain and agony from a misdiagnosis by an orthopaedic surgeon. I set out to conquer the problem myself – scared and ill-educated on the subject matter – and was faced by the foreign medical protocols and language.
As my stress levels grew, I was admitted to the Prince Charles Mental Health Unit by Dr. John Reinders under a de facto ITO. I was also forced to take anti-psychotic medication. This is because of some of the desperate language I was using, for example, “do I have to operate on myself?” and Dr. Reinders felt I may be a harm to myself.
I'd never been so low in my life. When taking anti-psychotic medication, you are very much unaware of your surroundings. It was only during a lull in the effect of the medication, that I decided I needed to get out of the hospital and do what I can for my ankle – I was convinced the doctors had erred and that this was a huge mistake. I requested a Psychiatric evaluation and was declared “in severe distress, but mentally healthy” and I was discharged.
I set about understanding ankle anatomy, conditions of the ankle and general medical protocols. I quickly learned that I had at least soft tissue impingement. Indeed, I had tissue trapped in the joint that was under permanent pressure due to the recent surgery – even when not weight bearing. This is as painful as you might imagine it to be and a little more given multiple pathologies.
I sought help from Dr. Andrew Wines (Foot & Ankle Orthopaedic Surgeon) in Sydney who prescribed an arthroscopic debridement. This was performed under GA on 11 December 2008. To quote his remark, “you had a chunk of tissue about the size of my finger in there”. I was immediately weight bearing post-operative and the local aneasthetic provided some relief. As a result of this anaesthesis, I was under the false impression that my troubles were over. They weren't.
After a few days I knew I still had a severe and painful problem though I no longer had the problem of tissue impingement. It felt like I had bone impingement on dorsiflexion and I sought answers from medical literature. I eventually stumbled on Anteromedial Osseous Impingement Syndrome for which MRI radiography is inconclusive for diagnosis. I used my January 2009 appointment with Dr. Sterling to ask for a request form for a CAT radiograph and weight-bearing Xray. Dr. Sterling also made an appointment with Dr. Michael Lutz to determine if he could unravel this mysterious problem of mine.
Upon obtaining these radiographs, I saw immediately that I had a bone spur in the location of my pain. I sought assistance from Dr. Andrew Wines (again in Sydney) who agreed with me to some extent but wanted a second opinion in order to ensure he was not suffering a bias. I applaud this decision. I used my upcoming appointment with Dr. Lutz to achieve this second opinion. Dr. Lutz agreed that an open incision to excise osteophytes on my tibia may be appropriate and I was informed of the risks .
Dr. Wines performed an arthrotomic tibial ostectomy on 04 March 2009 under GA at Royal North Shore Hospital. I flew home the next day – I was weight bearing without assistance. Again, the anaesthetic provided a false belief that my problems were over.
Unfortunately, I still have the same problem I started with – I cannot put my ankle into dorsiflexion. Many doctors might attribute this to the recent surgery, but I know I am experiencing precisely the same symptoms that I have done for the last 18 months. Although the localised and extreme pain caused by a bone spur has been resolved, I still have bone impingement on dorsiflexion that is not localised. I also know that this is due to a very definite mechanical limitation, since I have had a Physiotherapist in the past attempt to push my joint past this point with intense force to no avail.
As a result of this inability for dorsiflexion, my muscles have atrophied up to my thoracic spine. Subsequently, I find breathing difficult and any position uncomfortable except for lying down. This has caused immense stress especially while I have maintained a full-time job (Computing Science Researcher) and I am considering indefinite unpaid sick leave. Unfortunately, a consequence of this is that I will no longer be able to afford regular flights to Sydney for treatment, radiographs and so on, therefore, I must continue the battle under all circumstances and despite exhaustion.
I have long maintained that my symptoms are only observable while I am weight-bearing and in an attempt at dorsiflexion. This means that surgeons who operate cannot check for resolution of these symptoms, MRI and CAT radiographs cannot exhibit them and the only weight-bearing Xray I have was not in dorsiflexion because the Radiographer would not allow it (images only per requesting doctor instructions).
Unfortunately, I still have quite a large battle ahead but I am at a complete loss with respect to how I should go about it and that is why I have written to you, my state medical authority.
Is there a radiographic machine available in Queensland that will exhibit my bone impingement while in dorsiflexion and while weight-bearing? Better still, is there a doctor who is prepared to do the hard work of figuring this problem out? I am more than willing to make many sacrifices to ensure it. These are rhetorical questions – I don't know what the right questions are.
I am desperately seeking a diagnosis and treatment, 19 months after an initial injury and I know that my time is limited with regard to the amount of stress and pain that I can continue to endure. This is simply unsustainable.
Please advise.
Thank you for your time. Confidentiality is not requested and you may share this information with whoever you see fit.There was once a programming language called Jolly. It was exactly like what would become Java, except for a couple of differences.
The language did not have parametric polymorphism of any kind. No generics, nadda. In fact, the inventors of Jolly had never even heard of it.
The language did not have a common supertype. No java.lang.Object
The Jolly language was incredibly popular, especially among enterprise programmers. There were massive open source contributions written in Jolly, including one library, which was called list.reverse.
The list.reverse library had about 140 developers (and getting stronger!) across the world all working away. You see, since Jolly had no parametric polymorphism, every time you wanted to reverse a list of say, Bananas, you had to check if reverse was already written for Bananas in the library, or if not, write it and commit to HEAD.
An academic, Robin, was chuffing on a joint rolled in some bark on which he had scribbled the thesis for the pi-calculus, after having invented an advanced ML programming language (with generics), spent a few years launching a space probe with it, found the challenge uninteresting, then decided to take on the harder stuff, made the effort to let the Jolly developers in on a little secret, “Hey guys, parametric polymorphism – it was invented decades ago, has been formalised and shown to be useful in many domains, including this one.”
“Who was this guy!? How dare he interrupt us on our pursuit to solve real-world list reversing with this academic nonsense!” was the first post to the mailing list. The Jolly contributors were furious at the careless remark of this Robin guy who, as far as they were concerned, had never written a line of industry-grade software in his life.
“Guys, just saying. You don’t need to keep writing this library over and over. I thought you might like to know. Just introduce this language feature and you’re done. I’ve attached a patch.”
Well now didn’t this get under the nose of the Jolly contributors. All that hard work had just been undermined in a short email by this person who had never written a single line of Jolly in his entire life. What would he know about list reversing anyway!? We have years of experience!
The academic finished off his joint and visited his colleague down the hall, Hermann, who was about to publish a thesis on new findings in the Lie Algebra, “those guys really got upset eh?”, Hermann remarked. Robin, not giving much of a shit, made a noise through his nose then asked, “So what’s new?”
It’s now a few years since that email. The patch to Jolly was never looked at. The list.reverse developers recently released a version 5.0 of their library, which implements reverse for lists of every single class in the Jolly library, and includes a plug-in for every type in the most popular ORM library for Jolly. The project was also forked to include reverse for both arrays and lists and is now more popular than list.reverse.
Robin and Hermann have since forgotten that Jolly even exists. Their colleagues have advanced computational theory well beyond what will soon become Java.
As a follow-on to Further Understanding scala.Option, following are another 10 exercises (numbered 16 to 25). Included are solutions to the original 1 to 15 exercises. Instructions are in the comments.
// Scala version 2.8.0.final
// http://scala-tools.org/repo-releases/org/scala-tools/testing/scalacheck_2.8.0/1.7/scalacheck_2.8.0-1.7.jar/*
PART 1
======
Below are 15 exercises numbered 1 to 15. The task is to emulate the scala.Option API
without using Some/None subtypes, but instead using a fold (called a
catamorphism).
A couple of functions are already done (map, get)
to be used as an example. ScalaCheck tests are given below to
verify the work. The desired result is to have all tests passing.
The 15th exercise is not available in the existing Scala API so
instructions are given in the comments.
Part 2
======
Below are 10 exercises numbered 16 to 25. The task is to implement additional
methods for the Optional data type. These methods are not provided in the
scala.Option API so to determine the correct result requires reading the method
type signature and ensuring that the tests pass.
The 25th exercise is notable in that its signature says nothing about
scala.Option yet it is usable for Option (see the test for example).
Revision History
================
23/08/2010
* Initial revision
----------------
23/08/2010
* Fixed prop_getOrElse. Thanks Michael Bayne.
----------------
26/08/2010
* Add lazy annotation to orElse method.
----------------
01/09/2010
Added Part 2
02/09/2010
* Fixed mapOptionals test (why wasn't it failing?). Thanks Alec Zorab.
* Added comments including *** special note ***
*/
trait Optional[A] {
// single abstract method
def fold[X](some: A => X, none: => X): X
import Optional._
// Done for you.
def map[B](f: A => B): Optional[B] =
fold(f andThen some, none[B])
// Done for you.
// WARNING: undefined for None
def get: A =
fold(a => a, error("None.get"))
// Exercise 1
def flatMap[B](f: A => Optional[B]): Optional[B] =
fold(f, none)
// Exercise 2
// Rewrite map but use flatMap, not fold.
def mapAgain[B](f: A => B): Optional[B] =
flatMap(f andThen some)
// Exercise 3
def getOrElse(e: => A): A =
fold(s => s, e)
// Exercise 4
def filter(p: A => Boolean): Optional[A] =
fold(a => if(p(a)) some(a) else none, none)
// Exercise 5
def exists(p: A => Boolean): Boolean =
fold(p, false)
// Exercise 6
def forall(p: A => Boolean): Boolean =
fold(p, true)
// Exercise 7
def foreach(f: A => Unit): Unit =
fold(f, ())
// Exercise 8
def isDefined: Boolean =
fold(_ => true, false)
// Exercise 9
def isEmpty: Boolean =
fold(_ => false, true)
// Exercise 10
def orElse(o: => Optional[A]): Optional[A] =
fold(_ => this, o)
// Exercise 11
def toLeft[X](right: => X): Either[A, X] =
fold(Left(_), Right(right))
// Exercise 12
def toRight[X](left: => X): Either[X, A] =
fold(Right(_), Left(left))
// Exercise 13
def toList: List[A] =
fold(List(_), Nil)
// Exercise 14
def iterator: Iterator[A] =
fold(Iterator.single(_), Iterator.empty)
// Exercise 15 The Clincher!
// Return a none value if either this or the argument is none.
// Otherwise apply the function to the argument in some.
// Don't be afraid to use functions you have written.
// Better style, more points!
def applic[B](f: Optional[A => B]): Optional[B] =
f flatMap map
// Utility
def toOption: Option[A] = fold(Some(_), None)
// Utility
override def toString =
fold("some[" + _ + "]", "none")
// Utility
override def equals(o: Any) =
o.isInstanceOf[Optional[_]] && {
val q = o.asInstanceOf[Optional[_]]
fold(a => q.exists(a == _),
q.isEmpty)
}
}
object Optional {
// Done for you
def none[A]: Optional[A] = new Optional[A] {
def fold[X](some: A => X, none: => X) = none
}
// Done for you
def some[A](a: A): Optional[A] = new Optional[A] {
def fold[X](some: A => X, none: => X) = some(a)
}
// Utility
def fromOption[A](o: Option[A]): Optional[A] = o match {
case None => none
case Some(a) => some(a)
}
// *** Special note ***
// Some of these functions are likely to be familiar List functions,
// but with one specific distinction: in every covariant value appearing in
// the type signature, this value is wrapped in Optional.
// For example, the unwrapped:
// filter: (A => Boolean) => List[A] => List[A]
// and the wrapped:
// filterOptionals: (A => Optional[Boolean]) => List[A] => Optional[List[A]]
//
// There are other functions of a similar nature below.
// Exercise 16
// If a none is encountered, then return a none, otherwise,
// accumulate all the values in Optional.
def mapOptionals[A, B](f: A => Optional[B], a: List[A]): Optional[List[B]] =
error("todo")
// Exercise 17
// If a none is encountered, then return a none, otherwise,
// accumulate all the values in Optional.
def sequenceOptionals[A](a: List[Optional[A]]): Optional[List[A]] =
error("todo")
// Exercise 18
// Use sequenceOptionals
def mapOptionalsAgain[A, B](f: A => Optional[B], a: List[A]): Optional[List[B]] =
error("todo")
// Exercise 19
// Use mapOptionals
def sequenceOptionalsAgain[A](a: List[Optional[A]]): Optional[List[A]] =
error("todo")
// Exercise 20
// If a none is encountered, return none, otherwise,
// flatten/join by one level.
def joinOptionals[A](a: Optional[Optional[A]]): Optional[A] =
error("todo")
// Exercise 21
def filterOptionals[A](p: A => Optional[Boolean], a: List[A]): Optional[List[A]] =
error("todo")
// Exercise 22
def fillOptionals[A](n: Int, a: Optional[A]): Optional[List[A]] =
error("todo")
// Exercise 23
// Use sequenceOptionals
def fillOptionalsAgain[A](n: Int, a: Optional[A]): Optional[List[A]] =
error("todo")
// Exercise 24
// Methods mentioning Optional in the type signature are prohibited, except applic and map
def mapOptionalsYetAgain[A, B](f: A => Optional[B], a: List[A]): Optional[List[B]] =
error("todo")
// Consider: def joinOptional[A](a: Optional[Optional[A]]): Optional[A]
// This function "flattens" the Optional into a Some value if possible.
// It is not possible to write this using only applic and map (try it!).
// Bye bye Option-specificity!
// (setting up for Exercise 25)
trait Applic[F[_]] {
def point[A](a: A): F[A]
def applic[A, B](f: F[A => B], a: F[A]): F[B]
final def map[A, B](f: A => B, a: F[A]): F[B] =
applic(point(f), a)
}
object Applic {
implicit val OptionalApplic: Applic[Optional] = new Applic[Optional] {
def point[A](a: A): Optional[A] = some(a)
def applic[A, B](f: Optional[A => B], a: Optional[A]): Optional[B] = a applic f
}
}
// Exercise 25
// The Double-Clincher!
def mapWhatever[A, B, F[_]](f: A => F[B], a: List[A])(implicit z: Applic[F]): F[List[B]] =
error("todo")
}
import org.scalacheck._
import Arbitrary.arbitrary
import Prop._
object TestOptional extends Properties("Optional") {
import Optional._
implicit def ArbitraryOptional[A](implicit a: Arbitrary[A]): Arbitrary[Optional[A]] =
Arbitrary(arbitrary[Option[A]] map fromOption)
property("map") = forAll ((o: Optional[Int], f: Int => String) =>
(o map f).toOption == (o.toOption map f))
property("get") = forAll((o: Optional[Int]) =>
o.isDefined ==>
(o.get == o.toOption.get))
property("flatMap") = forAll((o: Optional[Int], f: Int => Optional[String]) =>
(o flatMap f).toOption == (o.toOption flatMap (f(_).toOption)))
property("mapAgain") = forAll ((o: Optional[Int], f: Int => String) =>
(o mapAgain f).toOption == (o map f).toOption)
property("getOrElse") = forAll ((o: Optional[Int], n: Int) =>
(o getOrElse n) == (o.toOption getOrElse n))
property("filter") = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o filter f).toOption == (o.toOption filter f))
property("exists") = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o exists f) == (o.toOption exists f))
property("forall") = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o forall f) == (o.toOption forall f))
property("foreach") = forAll ((o: Optional[Int], f: Int => Unit, n: Int) => {
var x: Int = n
var y: Int = x
o foreach (t => x = x + t)
o.toOption foreach (t => y = y + t)
x == y
})
property("isDefined") = forAll ((o: Optional[Int]) =>
(o.isDefined) == (o.toOption.isDefined))
property("isEmpty") = forAll ((o: Optional[Int]) =>
o.isEmpty == o.toOption.isEmpty)
property("orElse") = forAll ((o: Optional[Int], p: Optional[Int]) =>
(o orElse p).toOption == (o.toOption orElse p.toOption))
property("toLeft") = forAll ((o: Optional[Int], n: Int) =>
(o toLeft n) == (o.toOption toLeft n))
property("toRight") = forAll ((o: Optional[Int], n: Int) =>
(o toRight n) == (o.toOption toRight n))
property("toList") = forAll ((o: Optional[Int]) =>
o.toList == o.toOption.toList)
property("iterator") = forAll ((o: Optional[Int]) =>
o.iterator sameElements o.toOption.iterator)
// *** READ THIS COMMENT FIRST ***
// Note that scala.Option has no such equivalent to this method
// Therefore, reading this test may give away clues to how it might be solved.
// If you do not wish to spoil it, look away now and follow the
// instruction in the Exercise comment.
property("applic") = forAll ((o: Optional[Int => String], p: Optional[Int]) =>
(p applic o).toOption ==
(for(f <- o.toOption;
n <- p.toOption)
yield f(n)))
def trace[A](a: A) = {
println(a)
a
}
property("mapOptionals") = forAll((f: Int => Optional[String], o: List[Int]) =>
{
val i = o map f
mapOptionals(f, o) == (if(i forall (_.isDefined)) some(i map (_.get)) else none)
})
property("sequenceOptionals") = forAll((o: List[Optional[String]]) =>
sequenceOptionals(o) == (if(o exists (_.isEmpty)) none else some(o map (_.get))))
property("mapOptionalsAgain") = forAll((f: Int => Optional[String], o: List[Int]) =>
mapOptionalsAgain(f, o) == mapOptionals(f, o))
property("sequenceOptionalsAgain") = forAll((o: List[Optional[String]]) =>
sequenceOptionalsAgain(o) == sequenceOptionals(o))
property("joinOptionals") = forAll((o: Optional[Optional[String]]) =>
joinOptionals(o) == (if(o.isDefined && o.get.isDefined) o.get else none))
property("filterOptionals") = forAll((f: Int => Optional[Boolean], o: List[Int]) =>
filterOptionals(f, o) == (if(o exists (f(_).isEmpty)) none else some(o filter (f(_).get))))
property("fillOptionals") = forAll((n: Int, o: Optional[String]) =>
(n < 1000) ==> // prevent stack consumption
(fillOptionals(n, o) == (if(n <= 0) some(Nil) else (o map (List.fill(n)(_))))))
property("fillOptionalsAgain") = forAll((n: Int, o: Optional[String]) =>
(n < 1000) ==> // prevent stack consumption
(fillOptionalsAgain(n, o) == fillOptionals(n, o)))
property("mapOptionalsYetAgain") = forAll((f: Int => Optional[String], o: List[Int]) =>
mapOptionalsYetAgain(f, o) == mapOptionals(f, o))
property("mapWhatever") = forAll((f: Int => Optional[String], o: List[Int]) =>
mapWhatever(f, o) == mapOptionals(f, o))
/*
$ scala -classpath .:scalacheck_2.8.0-1.7.jar TestOptional
+ Optional.map: OK, passed 100 tests.
+ Optional.get: OK, passed 100 tests.
+ Optional.flatMap: OK, passed 100 tests.
+ Optional.mapAgain: OK, passed 100 tests.
+ Optional.getOrElse: OK, passed 100 tests.
+ Optional.filter: OK, passed 100 tests.
+ Optional.exists: OK, passed 100 tests.
+ Optional.forall: OK, passed 100 tests.
+ Optional.foreach: OK, passed 100 tests.
+ Optional.isDefined: OK, passed 100 tests.
+ Optional.isEmpty: OK, passed 100 tests.
+ Optional.orElse: OK, passed 100 tests.
+ Optional.toLeft: OK, passed 100 tests.
+ Optional.toRight: OK, passed 100 tests.
+ Optional.toList: OK, passed 100 tests.
+ Optional.iterator: OK, passed 100 tests.
+ Optional.applic: OK, passed 100 tests.
+ Optional.mapOptionals: OK, passed 100 tests.
+ Optional.sequenceOptionals: OK, passed 100 tests.
+ Optional.mapOptionalsAgain: OK, passed 100 tests.
+ Optional.sequenceOptionalsAgain: OK, passed 100 tests.
+ Optional.joinOptionals: OK, passed 100 tests.
+ Optional.filterOptionals: OK, passed 100 tests.
+ Optional.fillOptionals: OK, passed 100 tests.
+ Optional.fillOptionalsAgain: OK, passed 100 tests.
+ Optional.mapOptionalsYetAgain: OK, passed 100 tests.
+ Optional.mapWhatever: OK, passed 100 tests.
*/
}Of the 26 medical doctors I have met in the last couple of years, about 10 of them had this question before them in some way. All of them answered “no.” I am very confident this tiny sample set extrapolates – I doubt there is a doctor who would not say no.
They are all wrong.
Entrapment neuropathy of the superficial peroneal nerve is not a common condition, but one which I had after an ankle inversion sprain. The entrapment was 10cm proximal to the lateral malleolus at the deep fascia exit behind the peroneal muscles.
In order to achieve resolution of this problem, I had to publish an essay with citations and present it to several surgeons. My citations include every case study of this condition that currently exists and several orthopaedic text books.
My insistence that this was causing a significant problem and that I also had incomplete foot drop was met with deep scepticism. After all, the superficial peroneal nerve (SPN) is a cutaneous nerve that does not supply motor control. I knew this too of course, but I had no explanation. It is the deep peroneal nerve (DPN) which supplies motor control – the guy next door. Foot drop is often caused by an entrapment below and behind the knee before the nerve splits into these two branches, but I knew this was not the cause.
A marcaine/steroid injection into the SPN entrapment site immediately (within seconds) relieved some amount of foot drop. This too, was met with scepticism (?placebo), but I was adamant – there was an effect including a functional improvement.
An entrapment neuropathy of the superficial peroneal can cause foot drop by extending the nerve, and placing traction on the L5 nerve root. This will result in the expected fibrillation of the foot extensor muscles. Further, this is an extremely painful and distressing condition resulting in symptoms that can be very distracting from the actual etiology.
_I am not a medical expert, just an independent thinker who owns too many medical text books. _
Below are 15 (probably fun) exercises for anyone interested in obtaining a deeper understanding of scala.Option and algebraic data types in general. I could write the same in Haskell but this will require either type-classes or rank-n types (GHC extension), so I thought I’d give that a miss.
Instructions are in the comments. Let me know if there are any questions.
// Scala version 2.8.0.final
// http://scalacheck.googlecode.com/files/scalacheck_2.8.0-1.8-SNAPSHOT.jar
/*
Below are 15 exercises. The task is to emulate the scala.Option API
without using Some/None subtypes, but instead using a fold (called a
catamorphism).
A couple of functions are already done (map, get)
to be used as an example. ScalaCheck tests are given below to
verify the work. The desired result is to have all tests passing.
The 15th exercise is not available in the existing Scala API so
instructions are given in the comments.
Revision History
================
23/08/2010
Initial revision
----------------
23/08/2010
Fixed prop_getOrElse. Thanks Michael Bayne.
----------------
26/08/2010
Add lazy annotation to orElse method.
*/
trait Optional[A] {
// single abstract method
def fold[X](some: A => X, none: => X): X
import Optional._
// Done for you.
def map[B](f: A => B): Optional[B] =
fold(f andThen some, none[B])
// Done for you.
// WARNING: undefined for None
def get: A =
fold(a => a, error("None.get"))
// Exercise 1
def flatMap[B](f: A => Optional[B]): Optional[B] =
error("todo")
// Exercise 2
// Rewrite map but use flatMap, not fold.
def mapAgain[B](f: A => B): Optional[B] =
error("todo")
// Exercise 3
def getOrElse(e: => A): A =
error("todo")
// Exercise 4
def filter(p: A => Boolean): Optional[A] =
error("todo")
// Exercise 5
def exists(p: A => Boolean): Boolean =
error("todo")
// Exercise 6
def forall(p: A => Boolean): Boolean =
error("todo")
// Exercise 7
def foreach(f: A => Unit): Unit =
error("todo")
// Exercise 8
def isDefined: Boolean =
error("todo")
// Exercise 9
def isEmpty: Boolean =
error("todo")
// Exercise 10
def orElse(o: => Optional[A]): Optional[A] =
error("todo")
// Exercise 11
def toLeft[X](right: => X): Either[A, X] =
error("todo")
// Exercise 12
def toRight[X](left: => X): Either[X, A] =
error("todo")
// Exercise 13
def toList: List[A] =
error("todo")
// Exercise 14
def iterator: Iterator[A] =
error("todo")
// Exercise 15 The Clincher!
// Return a none value if either this or the argument is none.
// Otherwise apply the function to the argument in some.
// Don't be afraid to use functions you have written.
// Better style, more points!
def applic[B](f: Optional[A => B]): Optional[B] =
error("todo")
// Utility
def toOption: Option[A] = fold(Some(_), None)
}
object Optional {
// Done for you
def none[A]: Optional[A] = new Optional[A] {
def fold[X](some: A => X, none: => X) = none
}
// Done for you
def some[A](a: A): Optional[A] = new Optional[A] {
def fold[X](some: A => X, none: => X) = some(a)
}
// Utility
def fromOption[A](o: Option[A]): Optional[A] = o match {
case None => none
case Some(a) => some(a)
}
}
import org.scalacheck._
import Arbitrary.arbitrary
import Prop._
object TestOptional {
import Optional._
implicit def ArbitraryOptional[A](implicit a: Arbitrary[A]): Arbitrary[Optional[A]] =
Arbitrary(arbitrary[Option[A]] map fromOption)
val prop_map = forAll ((o: Optional[Int], f: Int => String) =>
(o map f).toOption == (o.toOption map f))
val prop_get = forAll((o: Optional[Int]) =>
o.isDefined ==>
(o.get == o.toOption.get))
val prop_flatMap = forAll((o: Optional[Int], f: Int => Optional[String]) =>
(o flatMap f).toOption == (o.toOption flatMap (f(_).toOption)))
val prop_mapAgain = forAll ((o: Optional[Int], f: Int => String) =>
(o mapAgain f).toOption == (o map f).toOption)
val prop_getOrElse = forAll ((o: Optional[Int], n: Int) =>
(o getOrElse n) == (o.toOption getOrElse n))
val prop_filter = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o filter f).toOption == (o.toOption filter f))
val prop_exists = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o exists f) == (o.toOption exists f))
val prop_forall = forAll ((o: Optional[Int], f: Int => Boolean) =>
(o forall f) == (o.toOption forall f))
val prop_foreach = forAll ((o: Optional[Int], f: Int => Unit, n: Int) => {
var x: Int = n
var y: Int = x
o foreach (t => x = x + t)
o.toOption foreach (t => y = y + t)
x == y
})
val prop_isDefined = forAll ((o: Optional[Int]) =>
(o.isDefined) == (o.toOption.isDefined))
val prop_isEmpty = forAll ((o: Optional[Int]) =>
o.isEmpty == o.toOption.isEmpty)
val prop_orElse = forAll ((o: Optional[Int], p: Optional[Int]) =>
(o orElse p).toOption == (o.toOption orElse p.toOption))
val prop_toLeft = forAll ((o: Optional[Int], n: Int) =>
(o toLeft n) == (o.toOption toLeft n))
val prop_toRight = forAll ((o: Optional[Int], n: Int) =>
(o toRight n) == (o.toOption toRight n))
val prop_toList = forAll ((o: Optional[Int]) =>
o.toList == o.toOption.toList)
val prop_iterator = forAll ((o: Optional[Int]) =>
o.iterator sameElements o.toOption.iterator)
// *** READ THIS COMMENT FIRST ***
// Note that scala.Option has no such equivalent to this method
// Therefore, reading this test may give away clues to how it might be solved.
// If you do not wish to spoil it, look away now and follow the
// instruction in the Exercise comment.
val prop_applic = forAll ((o: Optional[Int => String], p: Optional[Int]) =>
(p applic o).toOption ==
(for(f <- o.toOption;
n <- p.toOption)
yield f(n)))
val props =
List(
prop_map,
prop_get,
prop_flatMap,
prop_mapAgain,
prop_getOrElse,
prop_filter,
prop_exists,
prop_forall,
prop_foreach,
prop_isDefined,
prop_isEmpty,
prop_orElse,
prop_toLeft,
prop_toRight,
prop_toList,
prop_iterator,
prop_applic
)
/*
$ scala -classpath .:scalacheck_2.8.0-1.8-SNAPSHOT.jar TestOptional
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
*/
def main(args: Array[String]) {
props foreach (_.check)
}
}I have found that those who advocate for the practicality of Java as a programming language for solving software problems invariably have an incredibly poor understanding of programming language theory and poor general problem solving skills. However, almost always, an even poorer understanding of the Java programming language itself is most prominent.
Consequently, one cannot have a reasonable discussion about the merits of problem solving, using the Java programming language, or programming languages in general. However, one hopes that this sample set is biased and so one continues the search for a counter-example.
This is lamentable.
Functional Java 3.0 is released. As usual, requires any Java 1.5 (or above) runtime and the source can be compiled with any Java 1.5 compiler.
Support for Java 7 BGGA closures is dropped, since the function interfaces are now classes with abstract methods. Other useful additions abound. Have fun!
Below are three exercises using Scala. The instructions for each are in the comments. Exercises 1 and 2 must be completed before Exercise 3 (which is just a thinking exercise – no code).
A follow-on to these exercises will be coming.
Hope this helps!
// A typical data type with a single abstract method
case class Inter[A](f: Int => A) {
// which is a functor
def map[B](g: A => B): Inter[B] =
Inter(n => g(f(n)))
// and a monad (see unital below)
def flatMap[B](g: A => Inter[B]): Inter[B] =
Inter(n => g(f(n)).f(n))
}
// unital: A => F[A]
// Implementations for F=Option and F=Inter
object Unitals {
def unitalOption[A](a: A): Option[A] =
Some(a)
def unitalInter[A](a: A): Inter[A] =
Inter(_ => a)
}
// Exercises
//
// It is recommended to use only map, flatMap and unital* for
// Option or Inter when implementing the exercises below.
// Any other libraries are acceptable (e.g. List functions).
object Sequencing {
import Unitals._
// Exercise 1 of 3
// ===============
// Implement a function that returns None if the given list
// contains any None values, otherwise, all the Some values.
def sequenceOption[A](x: List[Option[A]]): Option[List[A]] =
error("todo")
// SOLUTIONx2 (ROT-13)
/*
1)
k.sbyqEvtug(havgnyBcgvba(Avy: Yvfg[N]))((n, o) => n syngZnc (k => o znc (k :: _)))
2)
k zngpu {
pnfr Avy => havgnyBcgvba(Avy)
pnfr u::g => u syngZnc (k => frdhraprBcgvba(g) znc (k :: _))
}
*/
// Exercise 2 of 3
// ===============
// Implement a function that returns an Inter that applies an Int
// to all the Inter implementations in the List of Inters and returns
// all the results.
def sequenceInter[A](x: List[Inter[A]]): Inter[List[A]] =
error("todo")
// SOLUTIONx2 (ROT-13)
/*
1)
k.sbyqEvtug(havgnyVagre(Avy: Yvfg[N]))((n, o) => n syngZnc (k => o znc (k :: _)))
2)
k zngpu {
pnfr Avy => havgnyVagre(Avy)
pnfr u::g => u syngZnc (k => frdhraprVagre(g) znc (k :: _))
}
*/
// Exercise 3 of 3
// ===============
// There is repetition in the above exercises.
// How might we be rid of it?
// That is for Part 2.
def main(args: Array[String]) {
def assertEquals[A](a1: A, a2: A) {
if(a1 != a2)
error("Assertion error. Expected: " + a1 + " Actual: " + a2)
}
def assertInterEquals[A](a1: Inter[A], a2: Inter[A]) {
val testInts = List(1, 2, 0, -7, -9, 113, -2048)
assertEquals(testInts.map(a1.f(_)), testInts.map(a2.f(_)))
}
// sequenceOption
assertEquals(sequenceOption(List(Some(7),
Some(8), Some(9))), Some(List(7, 8, 9)))
assertEquals(sequenceOption(List(Some(7), None, Some(9))),
None)
assertEquals(sequenceOption(List()),
Some(List()))
// sequenceInter
assertInterEquals(sequenceInter(List()),
Inter(_ => List()))
assertInterEquals(sequenceInter(List(Inter(1+),
Inter(2*))), Inter(n => List(1+n, 2*n)))
}
}A loose follow-on from Java Trivia.
I run a weekly Haskell session at my place of employment. We are just beginning. The intention is not so much to learn Haskell, but to learn deeper programming concepts so that we can apply them regardless of language – though to the extent that various languages permit.
Recently, we were discussing algebraic data types and we invented our own:
data Optional a = Full a | Empty deriving (Eq, Show)This is equivalent to:
fj.data.Option for Java
Data.Maybe for Haskell
scala.Option for Scala
option for F#
module Option for OCaml
Option for SML
option for Coq
We were writing a function with this type
Optional a -> a -> awhen a member of the audience said, “Why not just use Optional a -> a?” to which I responded, “That’s not possible to do in a consistent way.” That is, not only we shouldn’t, but we cannot do it, no matter what! By consistent here, I mean a total, terminating function. Telling programmers that something is not possible is often a little hasty, even if it is true, so I side-stepped any further discussion on this matter and carried on, promising further explanation, which follows.
Here I will prove it is not possible by exploiting the Curry-Howard Isomorphism. It is not intended to be deep or technical, only to display some of the possibilities of using “types as propositions, programs as proof” – to paraphrase the intention of C-H Isomorphism.
The essence of C-H is quite simple. If you write a type signature, you have also written a logical proposition. If you find at least one function that satisfies this signature, you have proven that proposition. Conversely, if you have a program, its existence proves its type (whether the programming language explicitly supplies that type or not). This program for a type is called an inhabitant of the type. Some types are uninhabited, for example: a -> b. That’s because this proposition is not true.
To state it logically, forall a b. a implies b is a false statement. You can determine this by a simple truth table:
a b a->b
0 0 1
0 1 1
1 0 0 <-- inconsistency
1 1 1In a previous post, I demonstrated a function that was once-inhabited using (a subset of – see the rules) Java. I knew it was once-inhabited before I gave the puzzle, meaning that every answer given should be the same (extensionally equivalent). Once-inhabited functions are very interesting, but not here – since we are looking for either:
At least one inhabitant (proof which I have claimed does not exist)
The absence of an inhabitant (proof negative)
So how can we prove or disprove Optional a -> a?
My claim is that it is uninhabited. You can disprove this claim by finding an inhabitant. However, the inability to find an inhabitant does not disprove the proposition – after all, we might just be having an unimaginative day! I am assuring you for now, that you will find no such inhabitant. Now I will prove that you won’t.
We first ask the question, what exactly is Optional a? We can provide a data structure of equivalence by exploiting the catamorphism for the data type:
type Optional a = forall x. (a -> x) -> x -> xThis data type is isomorphic (of the same one form) to our previous one and you can determine this by passing in the two constructors of the earlier data type to this isomorphic data type to produce an identity function:
let cata :: (a -> x) -> x -> x
cata Full Empty == idSide note: if you’re interested in doing the same for a Haskell list, see the foldr function denoting the list catamorphism (foldr (:) [] == id).
Therefore, our proposition to prove/disprove is now rewritten (remember that -> is right-associative):
forall a x. ((a -> x) -> x -> x) -> a)Using this, and the truth table for logical implication, we can find an answer by another truth table. Let us first assign some of the parts of this proposition to values for brevity (s being the proposition under investigation):
p = a -> x
q = x -> x
r = p -> q
s = r -> aLet us now draw the truth table:
a x p q r s
0 0 1 1 1 0 <-- inconsistency
0 1 1 1 1 0 <-- inconsistency
1 0 0 1 1 1
1 1 1 1 1 1We have now disproven the proposition Optional a -> a. It is not possible to inhabit this type signature consistently.
Further Reading:
As always, I hope this helps!
Implement the missing function body. These rules must be followed:
No using null
No throwing an exception/error
Function must terminate
No side-effecting
No type-casing (instanceof)
No type-casting
How many different ways of achieving the objective?
interface Function<A, B> {
B apply(A a);
}
class C {
static <A, B, C> Function<A, C> c(final Function<A, B> f,
final Function<B, C> g) {
.... todo
}
}Below is a data type that represents a list that has a maximum length of one. It is often useful in cases where null would otherwise be used.
Consider for example, the getHeaders method on HttpServletRequest which returns a String but might return null if there is no such header. Instead, a new API might return NoneOrOne<String> and do away with the use of null.
The idea of this exercise is to fill out the method bodies (remove the thrown Error) according to the comments without altering the method type. It is not permitted to use null or throw any exception. The tests at the bottom (see main method) should produce the specified results. At the moment, the code compiles, but will not execute successfully.
There are nine methods that need filling out. The tests are not exhaustive (use some intuition). Have fun! Questions are welcome.
// A list that is either empty or has one element.
public abstract class NoneOrOne<a> {
// The key abstract method (catamorphism).
public abstract <x> X fold(Thunk<x> none, Func<A, X> one);
// Produces an empty list.
public static <a> NoneOrOne<a> none() {
throw new Error("todo");
}
// Produces a list with the given element.
public static <a> NoneOrOne<a> one(final A a) {
throw new Error("todo");
}
// Returns true if this list is empty.
public boolean isEmpty() {
throw new Error("todo");
}
// Maps the given function on each element of this list.
public <b> NoneOrOne<b> map(final Func<A, B> f) {
throw new Error("todo");
}
// Filters the list on the given predicate.
// The element is retained if the predicate satisfies.
public NoneOrOne<a> filter(final Func<A, Boolean> p) {
throw new Error("todo");
}
// Applies the possible function on this list.
public <b> NoneOrOne<b> app(final NoneOrOne<Func<A, B>> f) {
throw new Error("todo");
}
// Binds the given function on this list.
public <b> NoneOrOne<b> bind(final Func<A, NoneOrOne<b>> f) {
throw new Error("todo");
}
// Returns the value held in this list.
// However, if it is empty, return the given default value.
public A get(final Thunk<a> def) {
throw new Error("todo");
}
// If this list is empty, return the given one.
// Otherwise, return this list.
public NoneOrOne<a> orElse(final NoneOrOne<a> els) {
throw new Error("todo");
}
// For debugging
public String toString() {
final StringBuilder s = new StringBuilder();
s.append('[');
fold(new Thunk<object>() {
public Object value() {
return null; // Java has no suitable unit type.
}
}, new Func<A, Object>() {
public Object apply(final A a) {
s.append(a);
return null; // Java has no suitable unit type.
}
});
return s.append(']').toString();
}
// TEST
public static void main(final String[] args) {
final NoneOrOne<integer> s = NoneOrOne.one(Integer.parseInt(args[0]));
final NoneOrOne<string> t = s.map(new Func<Integer, String>() {
public String apply(final Integer i) {
return new StringBuilder(Integer.valueOf(i * 123).toString()).reverse().toString();
}
});
final NoneOrOne<integer> u = s.filter(new Func<Integer, Boolean>() {
public Boolean apply(final Integer i) {
return i < 100;
}
});
final NoneOrOne<string> v = s.app(NoneOrOne.<Func<Integer, String>>one(
new Func<Integer, String>() {
public String apply(final Integer i) {
return String.valueOf(Math.pow(i, i));
}
}));
final NoneOrOne<string> w = s.bind(new Func<Integer, NoneOrOne<string>>() {
public NoneOrOne<string> apply(final Integer i) {
return i % 2 == 0 ?
one("it's even") :
i % 3 == 0 ?
one("it's divisible by 3 but not 6") :
NoneOrOne.<string>none();
}
});
final Integer x = s.get(new Thunk<integer>() {
public Integer value() {
return 42;
}
});
final NoneOrOne<integer> y = NoneOrOne.<integer>none().orElse(s);
/*
$ java NoneOrOne 122
[122]
[60051]
[]
[3.4347832971354663E254]
[it's even]
122
[122]
$ java -classpath /tmp/ NoneOrOne 12
[12]
[6741]
[12]
[8.916100448256E12]
[it's even]
12
[12]
*/
System.out.println(s);
System.out.println(t);
System.out.println(u);
System.out.println(v);
System.out.println(w);
System.out.println(x);
System.out.println(y);
}
}
// Laziness
interface Thunk<t> {
T value();
}
// Takes an A and produces a B
interface Func<A, B> {
B apply(A a);
}Follow-on from Haskell Exercises for Beginners
-- TOTAL marks: /66
module Exercises where
import Prelude hiding (sum, length, map, filter, maximum, reverse, succ, pred)
-- BEGIN Helper functions and data types
-- The custom list type
data List t = Nil | Cons t (List t) deriving Eq
instance (Show t) => Show (List t) where
show = show . toList
where
toList Nil = []
toList (Cons h t) = h : toList t
-- the custom numeric type
data Natural = Zero | Succ Natural deriving Eq
one = Succ Zero
two = Succ one
three = Succ two
instance Show Natural where
show = show . toInt
where
toInt Zero = 0
toInt (Succ x) = 1 + toInt x
-- functions over Natural that you may consider using
succ :: Natural -> Natural
succ = Succ
pred :: Natural -> Natural
pred Zero = error "bzzt. Zero has no predecessor in naturals"
pred (Succ x) = x
-- functions over List that you may consider using
foldRight :: (a -> b -> b) -> b -> List a -> b
foldRight _ b Nil = b
foldRight f b (Cons h t) = f h (foldRight f b t)
foldLeft :: (b -> a -> b) -> b -> List a -> b
foldLeft _ b Nil = b
foldLeft f b (Cons h t) = let b' = f b h in b' `seq` foldLeft f b' t
reduceRight :: (a -> a -> a) -> List a -> a
reduceRight _ Nil = error "bzzt. reduceRight on empty list"
reduceRight f (Cons h t) = foldRight f h t
reduceLeft :: (a -> a -> a) -> List a -> a
reduceLeft _ Nil = error "bzzt. reduceLeft on empty list"
reduceLeft f (Cons h t) = foldLeft f h t
-- END Helper functions and data types
-- BEGIN Exercises
-- Exercise 1
-- Relative Difficulty: 1
-- Correctness: 2.0 marks
-- Performance: 0.5 mark
-- Elegance: 0.5 marks
-- Total: 3
add :: Natural -> Natural -> Natural
add = error "todo"
-- Exercise 2
-- Relative Difficulty: 2
-- Correctness: 2.5 marks
-- Performance: 1 mark
-- Elegance: 0.5 marks
-- Total: 4
sum :: List Int -> Int
sum = error "todo"
-- Exercise 3
-- Relative Difficulty: 2
-- Correctness: 2.5 marks
-- Performance: 1 mark
-- Elegance: 0.5 marks
-- Total: 4
length :: List a -> Int
length = error "todo"
-- Exercise 4
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.0 mark
-- Elegance: 1.5 marks
-- Total: 7
map :: (a -> b) -> List a -> List b
map = error "todo"
-- Exercise 5
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
filter :: (a -> Bool) -> List a -> List a
filter = error "todo"
-- Exercise 6
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
append :: List a -> List a -> List a
append = error "todo"
-- Exercise 7
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
flatten :: List (List a) -> List a
flatten = error "todo"
-- Exercise 8
-- Relative Difficulty: 7
-- Correctness: 5.0 marks
-- Performance: 1.5 marks
-- Elegance: 1.5 mark
-- Total: 8
flatMap :: List a -> (a -> List b) -> List b
flatMap = error "todo"
-- Exercise 9
-- Relative Difficulty: 8
-- Correctness: 3.5 marks
-- Performance: 3.0 marks
-- Elegance: 2.5 marks
-- Total: 9
maximum :: List Int -> Int
maximum = error "todo"
-- Exercise 10
-- Relative Difficulty: 10
-- Correctness: 5.0 marks
-- Performance: 2.5 marks
-- Elegance: 2.5 marks
-- Total: 10
reverse :: List a -> List a
reverse = error "todo"
-- END Exercises
-- BEGIN Tests for Exercises
main :: IO ()
main =
let showNil = show (Nil :: List Int)
results =
[
-- add
("add",
show (add one two)
, show three),
("add",
show (add Zero two)
, show two),
-- sum
("sum",
show (sum (Cons 1 (Cons 2 (Cons 3 Nil))))
, show 6),
("sum",
show (sum Nil)
, show 0),
-- length
("length",
show (length (Cons 'a' (Cons 'b' (Cons 'c' Nil))))
, show 3),
("length",
show (length Nil)
, show 0),
-- map
("map",
show (map (+1) (Cons 1 (Cons 2 (Cons 3 Nil))))
, show (Cons 2 (Cons 3 (Cons 4 Nil)))),
("map",
show (map (+1) Nil)
, showNil),
-- filter
("filter",
show (filter even (Cons 1 (Cons 2 (Cons 3 Nil))))
, show (Cons 2 Nil)),
("filter",
show (filter even Nil)
, showNil),
-- append
("append",
show (append (Cons 1 (Cons 2 (Cons 3 Nil))) (Cons 4 Nil))
, show (Cons 1 (Cons 2 (Cons 3 (Cons 4 Nil))))),
("append",
show (append (Cons 1 (Cons 2 (Cons 3 Nil))) Nil)
, show (Cons 1 (Cons 2 (Cons 3 Nil)))),
-- flatten
("flatten",
show (flatten (Cons (Cons 1 (Cons 2 Nil)) (Cons (Cons 3 (Cons 4 Nil)) Nil)))
, show (Cons 1 (Cons 2 (Cons 3 (Cons 4 Nil))))),
-- flatMap
("flatMap",
show (flatMap (Cons 1 (Cons 2 (Cons 3 Nil))) (\n -> Cons (n+1) (Cons (n+2) Nil)))
, show (Cons 2 (Cons 3 (Cons 3 (Cons 4 (Cons 4 (Cons 5 Nil))))))),
-- maximum
("maximum",
show (maximum (Cons 3 (Cons 1 (Cons 2 Nil))))
, show 3),
-- reverse
("reverse",
show (reverse (Cons 1 (Cons 2 (Cons 3 Nil))))
, show (Cons 3 (Cons 2 (Cons 1 Nil))))
]
check (n, a, b) = do print ("=== " ++ n ++ " ===")
print (if a == b then "PASS" else "FAIL Expected: " ++ b ++ " Actual: " ++ a)
in mapM_ check results
-- END Tests for ExercisesRevised and including addendum.
Scala
// 1. Start here. Observe this trait
trait Monad[M[_]] {
def flatMap[A, B](a: M[A], f: A => M[B]): M[B]
def unital[A](a: A): M[A]
}
// A simple data type, which turns out to satisfy the above trait
case class Inter[A](f: Int => A)
// So does this.
case class Identity[A](a: A)
// Monad implementations
object Monad {
// 2. Replace error("todo") with an implementation
def ListMonad: Monad[List] = error("todo")
// 3. Replace error("todo") with an implementation
def OptionMonad: Monad[Option] = error("todo")
// 4. Replace error("todo") with an implementation
def InterMonad: Monad[Inter] = error("todo")
// 5. Replace error("todo") with an implementation
def IdentityMonad: Monad[Identity] = error("todo")
}
object MonadicFunctions {
// 6. Replace error("todo") with an implementation
def sequence[M[_], A](as: List[M[A]], m: Monad[M]): M[List[A]] =
error("todo")
// 7. Replace error("todo") with an implementation
def fmap[M[_], A, B](a: M[A], f: A => B, m: Monad[M]): M[B] =
error("todo")
// 8. Replace error("todo") with an implementation
def flatten[M[_], A](a: M[M[A]], m: Monad[M]): M[A] =
error("todo")
// 9. Replace error("todo") with an implementation
def apply[M[_], A, B](f: M[A => B], a: M[A], m: Monad[M]): M[B] =
error("todo")
// 10. Replace error("todo") with an implementation
def filterM[M[_], A](f: A => M[Boolean], as: List[A]
, m: Monad[M]): M[List[A]] =
error("todo")
// 11. Replace error("todo") with an implementation
def replicateM[M[_], A](n: Int, a: M[A], m: Monad[M]): M[List[A]] =
error("todo: flatMap n times to produce a list")
// 12. Replace error("todo") with an implementation
def lift2[M[_], A, B, C](f: (A, B) => C, a: M[A], b: M[B]
, m: Monad[M]): M[C] =
error("todo")
// lift3, lift4, etc. Interesting question: Can we have liftN?
}
object Main {
def main(args: Array[String]) {
import Monad._
import MonadicFunctions._
val plusOne = Inter(1+)
val multTwo = Inter(2*)
val squared = Inter(n => n*n)
val plus = (_: Int) + (_: Int)
val values = List(
// sequence
sequence(List(List(1, 2), List(3, 4)), ListMonad),
sequence(List(Some(7), Some(8), Some(9)), OptionMonad),
sequence(List(Some(7), None, Some(9)), OptionMonad),
sequence(List(plusOne, multTwo, squared), InterMonad) f 7,
sequence(List(Identity(7), Identity(4)), IdentityMonad),
// fmap
fmap(List(1, 2, 3), (x: Int) => x * 10, ListMonad),
fmap(Some(8), (x: Int) => x * 10, OptionMonad),
fmap(None: Option[Int], (x: Int) => x * 10, OptionMonad),
fmap(plusOne, (x: Int) => x * 10, InterMonad) f 7,
fmap(Identity(9), (x: Int) => x * 10, IdentityMonad),
// flatten
flatten(List(List(1, 2), List(3, 4)), ListMonad),
flatten(Some(Some(8)), OptionMonad),
flatten(Some(None: Option[Int]), OptionMonad),
flatten(None: Option[Option[Int]], OptionMonad),
flatten(Inter(a => Inter(a *)), InterMonad) f 7,
flatten(Identity(Identity(8)), IdentityMonad),
// apply
apply(List((a: Int) => a + 1,
(a: Int) => a * 2,
(a: Int) => a % 2), List(1, 2, 3), ListMonad),
apply(Some((a: Int) => a + 1), Some(8), OptionMonad),
apply(None: Option[Int => Int], Some(8), OptionMonad),
apply(Some((a: Int) => a + 1), None: Option[Int], OptionMonad),
apply(Inter(a => (b: Int) => a * b), Inter(1+), InterMonad) f 7,
apply(Identity((a: Int) => a + 1), Identity(7), IdentityMonad),
// filterM
filterM((a: Int) => List(a > 2, a % 2 == 0), List(1, 2, 3), ListMonad),
filterM((a: Int) => Some(a > 1), List(1, 2, 3), OptionMonad),
filterM((a: Int) => Inter(n => a * n % 2 == 0),
List(1, 2, 3), InterMonad) f 7,
filterM((a: Int) => Identity(a > 1), List(1, 2, 3), IdentityMonad),
// replicateM
replicateM(2, List(7, 8), ListMonad),
replicateM(2, Some(7), OptionMonad),
replicateM(2, plusOne, InterMonad) f 7,
replicateM(2, Identity(6), IdentityMonad),
// lift2
lift2(plus, List(1, 2), List(3, 4), ListMonad),
lift2(plus, Some(7), Some(8), OptionMonad),
lift2(plus, Some(7), None: Option[Int], OptionMonad),
lift2(plus, None: Option[Int], Some(8), OptionMonad)
)
val verify = List(
// sequence
List(List(1, 3), List(1, 4), List(2, 3), List(2, 4)),
Some(List(7, 8, 9)),
None,
List(8, 14, 49),
Identity(List(7, 4)),
// fmap
List(10, 20, 30),
Some(80),
None,
80,
Identity(90),
// flatten
List(1, 2, 3, 4),
Some(8),
None,
None,
49,
Identity(8),
// apply
List(2, 3, 4, 2, 4, 6, 1, 0, 1),
Some(9),
None,
None,
56,
Identity(8),
// filterM
List(List(3), Nil, List(2, 3), List(2), List(3),
Nil, List(2, 3), List(2)),
Some(List(2, 3)),
List(2),
Identity(List(2, 3)),
// replicateM
List(List(7, 7), List(7, 8), List(8, 7), List(8, 8)),
Some(List(7, 7)),
List(8, 8),
Identity(List(6, 6)),
// lift2
List(4, 5, 5, 6),
Some(15),
None,
None
)
for((a, b) <- values zip verify)
println(if(a == b) "PASS"
else "FAIL. Expected: " + b + " Actual: " + a)
}
}Haskell
{-# LANGUAGE RankNTypes #-}
-- 1. Start here. Observe this data type
data Monad' m = Monad' {
unital :: forall a. a -> m a,
flatMap :: forall a b. m a -> (a -> m b) -> m b
}
-- A simple data type, which turns out to satisfy the above trait
newtype Inter a = Inter { f :: Int -> a }
-- So does this.
newtype Identity a = Identity { a :: a }
deriving Show
-- *** Monad implementations ***
-- 2. Replace error "todo" with an implementation
listMonad :: Monad' []
listMonad = error "todo"
-- 3. Replace error "todo" with an implementation
maybeMonad :: Monad' Maybe
maybeMonad = error "todo"
-- 4. Replace error "todo" with an implementation
interMonad :: Monad' Inter
interMonad = error "todo"
-- 5. Replace error "todo" with an implementation
identityMonad :: Monad' Identity
identityMonad = error "todo"
-- *** Monadic functions ***
-- 6. Replace error "todo" with an implementation
sequence' :: [m a] -> Monad' m -> m [a]
sequence' = error "todo"
-- 7. Replace error "todo" with an implementation
fmap' :: m a -> (a -> b) -> Monad' m -> m b
fmap' = error "todo"
-- 8. Replace error "todo" with an implementation
flatten :: m (m a) -> Monad' m -> m a
flatten = error "todo"
-- 9. Replace error "todo" with an implementation
apply :: m (a -> b) -> m a -> Monad' m -> m b
apply = error "todo"
-- 10. Replace error "todo" with an implementation
filterM' :: (a -> m Bool) -> [a] -> Monad' m -> m [a]
filterM' = error "todo"
-- 11. Replace error "todo" with an implementation
replicateM' :: Int -> m a -> Monad' m -> m [a]
replicateM' = error "todo: flatMap n times to produce a list"
-- 12. Replace error "todo" with an implementation
lift2 :: (a -> b -> c) -> m a -> m b -> Monad' m -> m c
lift2 = error "todo"
-- lift3, lift4, etc. Interesting question: Can we have liftN?
main :: IO ()
main =
let plusOne = Inter (1+)
multTwo = Inter (2*)
squared = Inter (\n -> n*n)
s x = show x
(%) = f
values =
[
-- sequence'
s (sequence' [[1, 2], [3, 4]] listMonad),
s (sequence' [Just 7, Just 8, Just 9] maybeMonad),
s (sequence' [Just 7, Nothing, Nothing] maybeMonad),
s (sequence' [plusOne, multTwo, squared] interMonad % 7),
s (sequence' [Identity 7, Identity 4] identityMonad),
-- fmap'
s (fmap' [1..3] (*10) listMonad),
s (fmap' (Just 8) (*10) maybeMonad),
s (fmap' Nothing (*10) maybeMonad),
s (fmap' plusOne (*10) interMonad % 7),
s (fmap' (Identity 9) (*10) identityMonad),
-- flatten
s (flatten [[1, 2], [3, 4]] listMonad),
s (flatten (Just (Just 8)) maybeMonad),
s (flatten (Just (Nothing :: Maybe Int)) maybeMonad),
s (flatten (Nothing :: Maybe (Maybe Int)) maybeMonad),
s (flatten (Inter (Inter . (*))) interMonad % 7),
s (flatten (Identity (Identity 8)) identityMonad),
-- apply
s (apply [(+1), (*2), (`mod` 2)] [1..3] listMonad),
s (apply (Just (+1)) (Just 8) maybeMonad),
s (apply (Nothing :: Maybe (Int -> Int)) (Just 8) maybeMonad),
s (apply (Just (+1)) (Nothing :: Maybe Int) maybeMonad),
s (apply (Inter (*)) (Inter (1+)) interMonad % 7),
s (apply (Identity (+1)) (Identity 7) identityMonad),
-- filterM'
s (filterM' (\a -> [a > 2, a `mod` 2 == 0]) [1..3] listMonad),
s (filterM' (\a -> Just (a > 1)) [1..3] maybeMonad),
s (filterM' (\a -> Inter (\n -> a * n `mod` 2 == 0)) [1..3]
interMonad % 7),
s (filterM' (Identity . (>1)) [1..3] identityMonad),
-- replicateM'
s (replicateM' 2 [7, 8] listMonad),
s (replicateM' 2 (Just 7) maybeMonad),
s (replicateM' 2 plusOne interMonad % 7),
s (replicateM' 2 (Identity 6) identityMonad),
-- lift2
s (lift2 (+) [1, 2] [3, 4] listMonad),
s (lift2 (+) (Just 7) (Just 8) maybeMonad),
s (lift2 (+) (Just 7) (Nothing :: Maybe Int) maybeMonad),
s (lift2 (+) (Nothing :: Maybe Int) (Just 8) maybeMonad)
]
verify =
[
-- sequence'
s ([[1, 3], [1, 4], [2, 3], [2, 4]]),
s (Just [7..9]),
s (Nothing :: Maybe Int),
s [8, 14, 49],
s (Identity [7, 4]),
-- fmap'
s [10, 20, 30],
s (Just 80),
s (Nothing :: Maybe Int),
s 80,
s (Identity 90),
-- flatten
s [1..4],
s (Just 8),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int),
s 49,
s (Identity 8),
-- apply
s [2, 3, 4, 2, 4, 6, 1, 0, 1],
s (Just 9),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int),
s 56,
s (Identity 8),
-- filterM'
s [[3], [], [2, 3], [2], [3], [], [2, 3], [2]],
s (Just [2, 3]),
s [2],
s (Identity [2, 3]),
-- replicateM
s [[7, 7], [7, 8], [8, 7], [8, 8]],
s (Just [7, 7]),
s [8, 8],
s (Identity [6, 6]),
-- lift2
s [4, 5, 5, 6],
s (Just 15),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int)
]
in mapM_
(\(a, b) ->
print(if a == b
then "PASS"
else "FAIL. Expected: " ++ b ++ " Actual: " ++ a))
(values `zip` verify)Following is a test harness that should print a series of PASS when executed against a correct solution to the original Monad Exercises in Scala. These exercises include a Haskell version and a test harness for this is also found below.
I have also written a complete solution in Scala and same again for Haskell (clicking either link will give away the answer).
object Main {
def main(args: Array[String]) {
import Monad._
import MonadicFunctions._
val plusOne = Inter(1+)
val multTwo = Inter(2*)
val squared = Inter(n => n*n)
val plus = (_: Int) + (_: Int)
val values = List(
// sequence
sequence(List(List(1, 2), List(3, 4)), ListMonad),
sequence(List(Some(7), Some(8), Some(9)), OptionMonad),
sequence(List(Some(7), None, Some(9)), OptionMonad),
sequence(List(plusOne, multTwo, squared), InterMonad) f 7,
sequence(List(Identity(7), Identity(4)), IdentityMonad),
// fmap
fmap(List(1, 2, 3), (x: Int) => x * 10, ListMonad),
fmap(Some(8), (x: Int) => x * 10, OptionMonad),
fmap(None: Option[Int], (x: Int) => x * 10, OptionMonad),
fmap(plusOne, (x: Int) => x * 10, InterMonad) f 7,
fmap(Identity(9), (x: Int) => x * 10, IdentityMonad),
// flatten
flatten(List(List(1, 2), List(3, 4)), ListMonad),
flatten(Some(Some(8)), OptionMonad),
flatten(Some(None: Option[Int]), OptionMonad),
flatten(None: Option[Option[Int]], OptionMonad),
flatten(Inter(a => Inter(a *)), InterMonad) f 7,
flatten(Identity(Identity(8)), IdentityMonad),
// apply
apply(List((a: Int) => a + 1,
(a: Int) => a * 2,
(a: Int) => a % 2), List(1, 2, 3), ListMonad),
apply(Some((a: Int) => a + 1), Some(8), OptionMonad),
apply(None: Option[Int => Int], Some(8), OptionMonad),
apply(Some((a: Int) => a + 1), None: Option[Int], OptionMonad),
apply(Inter(a => (b: Int) => a * b), Inter(1+), InterMonad) f 7,
apply(Identity((a: Int) => a + 1), Identity(7), IdentityMonad),
// filterM
filterM((a: Int) => List(a > 2, a % 2 == 0), List(1, 2, 3), ListMonad),
filterM((a: Int) => Some(a > 1), List(1, 2, 3), OptionMonad),
filterM((a: Int) => Inter(n => a * n % 2 == 0),
List(1, 2, 3), InterMonad) f 7,
filterM((a: Int) => Identity(a > 1), List(1, 2, 3), IdentityMonad),
// replicateM
replicateM(2, List(7, 8), ListMonad),
replicateM(2, Some(7), OptionMonad),
replicateM(2, plusOne, InterMonad) f 7,
replicateM(2, Identity(6), IdentityMonad),
// lift2
lift2(plus, List(1, 2), List(3, 4), ListMonad),
lift2(plus, Some(7), Some(8), OptionMonad),
lift2(plus, Some(7), None: Option[Int], OptionMonad),
lift2(plus, None: Option[Int], Some(8), OptionMonad)
)
val verify = List(
// sequence
List(List(1, 3), List(1, 4), List(2, 3), List(2, 4)),
Some(List(7, 8, 9)),
None,
List(8, 14, 49),
Identity(List(7, 4)),
// fmap
List(10, 20, 30),
Some(80),
None,
80,
Identity(90),
// flatten
List(1, 2, 3, 4),
Some(8),
None,
None,
49,
Identity(8),
// apply
List(2, 3, 4, 2, 4, 6, 1, 0, 1),
Some(9),
None,
None,
56,
Identity(8),
// filterM
List(List(3), Nil, List(2, 3), List(2), List(3),
Nil, List(2, 3), List(2)),
Some(List(2, 3)),
List(2),
Identity(List(2, 3)),
// replicateM
List(List(7, 7), List(7, 8), List(8, 7), List(8, 8)),
Some(List(7, 7)),
List(8, 8),
Identity(List(6, 6)),
// lift2
List(4, 5, 5, 6),
Some(15),
None,
None
)
for((a, b) <- values zip verify)
println(if(a == b) "PASS"
else "FAIL. Expected: " + b + " Actual: " + a)
}
}Haskell main function which should print a series of PASS when executed against the original Monad Exercises in Scala.
main :: IO ()
main =
let plusOne = Inter (1+)
multTwo = Inter (2*)
squared = Inter (\n -> n*n)
s x = show x
(%) = f
values =
[
-- sequence'
s (sequence' [[1, 2], [3, 4]] listMonad),
s (sequence' [Just 7, Just 8, Just 9] maybeMonad),
s (sequence' [Just 7, Nothing, Nothing] maybeMonad),
s (sequence' [plusOne, multTwo, squared] interMonad % 7),
s (sequence' [Identity 7, Identity 4] identityMonad),
-- fmap'
s (fmap' [1..3] (*10) listMonad),
s (fmap' (Just 8) (*10) maybeMonad),
s (fmap' Nothing (*10) maybeMonad),
s (fmap' plusOne (*10) interMonad % 7),
s (fmap' (Identity 9) (*10) identityMonad),
-- flatten
s (flatten [[1, 2], [3, 4]] listMonad),
s (flatten (Just (Just 8)) maybeMonad),
s (flatten (Just (Nothing :: Maybe Int)) maybeMonad),
s (flatten (Nothing :: Maybe (Maybe Int)) maybeMonad),
s (flatten (Inter (Inter . (*))) interMonad % 7),
s (flatten (Identity (Identity 8)) identityMonad),
-- apply
s (apply [(+1), (*2), (`mod` 2)] [1..3] listMonad),
s (apply (Just (+1)) (Just 8) maybeMonad),
s (apply (Nothing :: Maybe (Int -> Int)) (Just 8) maybeMonad),
s (apply (Just (+1)) (Nothing :: Maybe Int) maybeMonad),
s (apply (Inter (*)) (Inter (1+)) interMonad % 7),
s (apply (Identity (+1)) (Identity 7) identityMonad),
-- filterM'
s (filterM' (\a -> [a > 2, a `mod` 2 == 0]) [1..3] listMonad),
s (filterM' (\a -> Just (a > 1)) [1..3] maybeMonad),
s (filterM' (\a -> Inter (\n -> a * n `mod` 2 == 0)) [1..3]
interMonad % 7),
s (filterM' (Identity . (>1)) [1..3] identityMonad),
-- replicateM'
s (replicateM' 2 [7, 8] listMonad),
s (replicateM' 2 (Just 7) maybeMonad),
s (replicateM' 2 plusOne interMonad % 7),
s (replicateM' 2 (Identity 6) identityMonad),
-- lift2
s (lift2 (+) [1, 2] [3, 4] listMonad),
s (lift2 (+) (Just 7) (Just 8) maybeMonad),
s (lift2 (+) (Just 7) (Nothing :: Maybe Int) maybeMonad),
s (lift2 (+) (Nothing :: Maybe Int) (Just 8) maybeMonad)
]
verify =
[
-- sequence'
s ([[1, 3], [1, 4], [2, 3], [2, 4]]),
s (Just [7..9]),
s (Nothing :: Maybe Int),
s [8, 14, 49],
s (Identity [7, 4]),
-- fmap'
s [10, 20, 30],
s (Just 80),
s (Nothing :: Maybe Int),
s 80,
s (Identity 90),
-- flatten
s [1..4],
s (Just 8),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int),
s 49,
s (Identity 8),
-- apply
s [2, 3, 4, 2, 4, 6, 1, 0, 1],
s (Just 9),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int),
s 56,
s (Identity 8),
-- filterM'
s [[3], [], [2, 3], [2], [3], [], [2, 3], [2]],
s (Just [2, 3]),
s [2],
s (Identity [2, 3]),
-- replicateM
s [[7, 7], [7, 8], [8, 7], [8, 8]],
s (Just [7, 7]),
s [8, 8],
s (Identity [6, 6]),
-- lift2
s [4, 5, 5, 6],
s (Just 15),
s (Nothing :: Maybe Int),
s (Nothing :: Maybe Int)
]
in mapM_
(\(a, b) ->
print(if a == b
then "PASS"
else "FAIL. Expected: " ++ b ++ " Actual: " ++ a))
(values `zip` verify)A beginner is confused about Haskell’s type-classes and so asks the question, “What is a type-class?” The response is often devastating, “You know, like Java or C# interfaces.” This wildly misleading statement can leave the beginner in a state of disrepair. I’ll tell you why but first I must emphasise.
Type-classes are nothing like interfaces (emphasis on nothing).
Haskell has something like interfaces. They are called data types and are expressed using the data or newtype keywords. Languages like Java/C# have nothing like type-classes; there is not even a close analogy. Consider for example, Java’s [Comparator](http://java.sun.com/javase/6/docs/api/java/util/Comparator.html) interface. We would express this in Haskell like so:
newtype Comparator a = C { compare :: a -> a -> Int }Then if we wanted to sort a list, the type would be sort :: Comparator a -> [a] -> [a]. Notice the explicit passing of the Comparator that would be required at the call site. This is just like Java.
Now suppose we did something that Java cannot do. We used a type-class.
class Comparator a where
compare :: a -> a -> IntThe type for sorting a list now becomes sort :: Comparator a => [a] -> [a]. This is just like the previous signature except for the way the left-most arrow is written. This is an important distinction. When the caller uses this function, it implicitly passes the Comparator. Also, the type-class instance is decoupled from the data type. These are essential properties of type-classes. Indeed, it is its single-most defining property and since Java/C# have nothing like this, then it has nothing like type-classes.
Scala has implicit parameters which give you the ability to implement the essential property of type-classes (and more). Therefore, Scala does have something very much like type-classes. This is evident in a library such as Scalaz.
But let’s try to save the idea.
Java has implicit type-conversion by virtue of inheritance. For example, a method that accepts a T can be passed a U and its implicit conversion to a T is denoted by the way of U extends T. Notice that no side-effect can be performed during this conversion. This is unlike Scala’s implicit where it’s simply a bad idea, not enforced (Scala also has inheritance like Java).
So, if you are to say type-classes are like anything in these languages, it’s sort-of-like-yeah-ok-not-really inheritance. However, I’m sure you’ll agree, this will only cause confusion for the poor beginner, so it’s best not to draw the analogy at all.
Type-classes are a new concept to people coming from Java/C#. It is most appropriate to explain it as a new concept. I often use the contention between using java.util.Comparable, where the caller has the convenience of implicitly pass the implementation by way of inheritance but inconvenience of carrying the implementation with the data type versus using java.util.Comparator where the caller has the convenience of decoupling the implementation from the data type but requiring explicit passing at the call site. Type-classes (and Scala implicits) resolve this contention with a new concept.
Here are some slides to a short talk I gave a few weeks ago.
Hoping to get less ridiculous (i.e. more insightful) blog comments…
Scalaz now has an IRC channel.
irc://irc.freenode.net/#scalaz
A result of discussion in the #scala IRC channel.
A colleague has asked me to convert this to Haskell, which I have done below.
The trait Monad answers the question “What does monad mean?”
The object Monad answers the question “What are some examples?”
The object MonadicFunctions answers the question “What are the practical implications?”
If there are any questions or you get stuck, the #scala or #scalaz channel on Freenode could help out.
// 1. Start here. Observe this trait
trait Monad[M[_]] {
def flatMap[A, B](a: M[A], f: A => M[B]): M[B]
def unital[A](a: A): M[A]
}
// A simple data type, which turns out to satisfy the above trait
case class Inter[A](f: Int => A)
// So does this.
case class Identity[A](a: A)
// Monad implementations
object Monad {
// 2. Replace error("todo") with an implementation
def ListMonad: Monad[List] = error("todo")
// 3. Replace error("todo") with an implementation
def OptionMonad: Monad[Option] = error("todo")
// 4. Replace error("todo") with an implementation
def InterMonad: Monad[Inter] = error("todo")
// 5. Replace error("todo") with an implementation
def IdentityMonad: Monad[Identity] = error("todo")
}
object MonadicFunctions {
// 6. Replace error("todo") with an implementation
def sequence[M[_], A](as: List[M[A]], m: Monad[M]): M[List[A]] =
error("todo")
// 7. Replace error("todo") with an implementation
def fmap[M[_], A, B](a: M[A], f: A => B, m: Monad[M]): M[B] =
error("todo")
// 8. Replace error("todo") with an implementation
def flatten[M[_], A](a: M[M[A]], m: Monad[M]): M[A] =
error("todo")
// 9. Replace error("todo") with an implementation
def apply[M[_], A, B](f: M[A => B], a: M[A], m: Monad[M]): M[B] =
error("todo")
// 10. Replace error("todo") with an implementation
def filterM[M[_], A](f: A => M[Boolean], as: List[A]
, m: Monad[M]): M[List[A]] =
error("todo")
// 11. Replace error("todo") with an implementation
def replicateM[M[_], A](n: Int, a: M[A], m: Monad[M]): M[List[A]] =
error("todo: flatMap n times to produce a list")
// 12. Replace error("todo") with an implementation
def lift2[M[_], A, B, C](f: (A, B) => C, a: M[A], b: M[B]
, m: Monad[M]): M[C] =
error("todo")
// lift3, lift4, etc. Interesting question: Can we have liftN?
}Haskell
The data Monad' answers the question “What does monad mean?”
The functions under *** Monad implementations *** answers the question “What are some examples?”
The functions under *** Monadic Functions *** answers the question “What are the practical implications?”
{-# LANGUAGE RankNTypes #-}
-- 1. Start here. Observe this data type
data Monad' m = Monad' {
unital :: forall a. a -> m a,
flatMap :: forall a b. m a -> (a -> m b) -> m b
}
-- A simple data type, which turns out to satisfy the above trait
newtype Inter a = Inter { f :: Int -> a }
-- So does this.
newtype Identity a = Identity { a :: a }
deriving Show
-- *** Monad implementations ***
-- 2. Replace error "todo" with an implementation
listMonad :: Monad' []
listMonad = error "todo"
-- 3. Replace error "todo" with an implementation
maybeMonad :: Monad' Maybe
maybeMonad = error "todo"
-- 4. Replace error "todo" with an implementation
interMonad :: Monad' Inter
interMonad = error "todo"
-- 5. Replace error "todo" with an implementation
identityMonad :: Monad' Identity
identityMonad = error "todo"
-- *** Monadic functions ***
-- 6. Replace error "todo" with an implementation
sequence' :: [m a] -> Monad' m -> m [a]
sequence' = error "todo"
-- 7. Replace error "todo" with an implementation
fmap' :: m a -> (a -> b) -> Monad' m -> m b
fmap' = error "todo"
-- 8. Replace error "todo" with an implementation
flatten :: m (m a) -> Monad' m -> m a
flatten = error "todo"
-- 9. Replace error "todo" with an implementation
apply :: m (a -> b) -> m a -> Monad' m -> m b
apply = error "todo"
-- 10. Replace error "todo" with an implementation
filterM' :: (a -> m Bool) -> [a] -> Monad' m -> m [a]
filterM' = error "todo"
-- 11. Replace error "todo" with an implementation
replicateM' :: Int -> m a -> Monad' m -> m [a]
replicateM' = error "todo: flatMap n times to produce a list"
-- 12. Replace error "todo" with an implementation
lift2 :: (a -> b -> c) -> m a -> m b -> Monad' m -> m c
lift2 = error "todo"
-- lift3, lift4, etc. Interesting question: Can we have liftN?Because there is no such thing as a big application. There is only bigger or smaller. This is a central tenet of functional programming. “Big application” is a euphemism for “My idea of programming does not scale beyond this point.” You don’t realise how much information you give away when you ask this question.
So can we can stop with the piffle and get on with the interesting and important stuff? Ta.
I used to work for IBM on the Java implementation. I learned the language inside-out. I did all those Sun certifications and other spanky things. I wanted to understand what a lot of people alleged was so special. I didn’t ever find it.
I have found that few people can tell me the answer to this question. If you don’t know the answer, don’t fret; it’s not the important part.
method(s1.charAt(i), s2.charAt(j));Assuming
s1ands2are both of the typejava.lang.String, then which call tocharAtwill occur first?
Many people would correctly guess at the left-most one. This is correct and is mandated by the specification.
However, on introspection, the reason nobody really knows is because it doesn’t matter. If the specification implementation had a bug and executed the right-most call first, then we, the programmer, would never even know. We gloss over this every day when we read Java code.
However, does this hold for all functions? What if it was something other than charAt? No, unfortunately, this only holds true for a specific set of functions. The charAt function is referentially transparent. For any given String and any given int then charAt will consistently return the same char. This is true for other referentially transparent functions too, but not any arbitrary function. Imagine if charAt did a database call or something like that!
Let us suppose now a new language feature that enforced the referential transparency of our functions. If it is referentially transparent, the compiler makes sure of it. Now imagine a new language where every function was referentially transparent.
All of a sudden, in the blink of an imagined hypothetical, the explicit order of invocation is no longer important. Just like that, poof, gone.
Welcome to the beginning of an understanding of the essence of functional programming.
Have fun! :)
I have found that many classes are created for the specific purpose of a
sequencefunction in the((->) t)monad, particularly in Java, C# and Python. Create a class, with a constructor that takes an argument (t) so that one may call many of its methods, each of which has access to t.
sequence :: [m a] -> m [a]
sequence* :: [t -> a] -> t -> [a]If we consider the type of t which we shall call Swizzle and the created class we shall call SwizzleManager then
// A constructor accepting a Swizzle
SwizzleManager m = new SwizzleManager(t);
// One of the following usually follow:
// A list constructed by the results of executing several methods on 'm'
List<r> = { m.a(x), m.b(y), m.c(z) }
// A loop over a list of the results of executing several methods on 'm'
for(R r : { m.a(x), m.b(y), m.c(z) }) {
use(r);
}
// A list of effects to execute using 'm'
m.a(x);
m.b(y);
m.c(z);In a previous post, I mentioned a small library for validating using an applicative functor pattern with a semigroup for accumulating errors using Haskell, Scala and Java programming languages. In this post, I will give a set up for an example usage, but not necessarily a complete example. This is left as an exercise and may be elaborated on in a future post.
I will start with Java. First we must decide how we are going to accumulate errors. I have decided to store them in a LinkedList. In more practical languages with a better collections library, we would probably use something else. We will use something else for Scala and Haskell (later!), or you could use the Functional Java extension. In the meantime, we will use java.util.LinkedList. We start by writing its Semigroup implementation:
public static <a> Semigroup<LinkedList<a>> LinkedListSemigroup() {
return new Semigroup<LinkedList<a>>() {
public LinkedList<a> append(final LinkedList<a> a1,
final LinkedList<a> a2) {
final LinkedList<a> r = new LinkedList<a>(a1);
r.addAll(a2);
return r;
}
};
}This is very straight-forward. In the previous example, I mentioned a class Person that is made of an age and a name. The age is an integer between 0 and 130 while the name is any string that starts with an upper-case character. Let’s write these data types:
// int wrapper between 0 and 130
class Age {
private final int i;
private Age(final int i) { this.i = i; }
public int value() { return i; }
public static Age age(final int i) {
if(i <= 0 || i >= 130)
throw new Error("out of range");
else
return new Age(i);
}
}And here is Name:
// String wrapper starts with upper-case
class Name {
private final String s;
private Name(final String s) { this.s = s; }
public String value() { return s; }
public static Name name(final String s) {
if(s.isEmpty() || !Character.isUpperCase(s.charAt(0)))
throw new java.lang.Error();
else
return new Name(s);
}
}I won’t bother writing the Person data type, but it is sufficient to say it will have an Age field and a Name field.
Now for validation. Suppose we have two string values; one each for age and name. We would like to check these for validation and return either one or more error messages (String) or a Person. More succinctly, we want a function with the type:
String -> String -> Validation<LinkedList<String>, Person>>How are we going to achieve this function? First we must say how to create an Age from a String or an error message if we cannot:
String -> Validation<LinkedList<String>, Age>>and same for Name
String -> Validation<LinkedList<String, Name>>We also need a function to create a Person from an Age and a Name
Age -> Name -> PersonThis is simple. It’s the Person constructor.
So to sum up, we need to write a function with this type:
Arguments:
*
F<String, Validation<LinkedList<string>, Age>>>*
F<String, Validation<LinkedList<string>, Name>>>*
F<Age, F<Name, Person>>*
Semigroup<LinkedList<string>>Return type:
F<String, F<String, <Validation<LinkedList<string>, Person>>>>Of course such a function is likely to be polymorphic, rather than specifying concrete types. I recommend starting by writing a function with this type:
Arguments:
*
F<T, F<U, V>>*
F<A, Validation<E, T>>*
F<B, Validation<E, U>>Return type:
F<A, F<B, Validation<E, V>>This function can be written by using the constructs mentioned in the previous post. I’m out of breath. Java is incredibly laborious.
Scala and Haskell for another time!
Sanjiv is an ex-colleague of mine who recently gave an excellent presentation at Brisbane Functional Programming Group. His presentation was on the use of the disjoint union algebraic data type for representing error handling or “validation”. This data type is often called Either. Sanjiv used the Scala version for his presentation.
Here I am going to write a data type that is just like (isomorphic to) Either called Validation. There will be two constructors for failure and success. I will be using Haskell, Scala and Java. I am going to present a function that is mentioned in an excellent paper called Applicative Programming with Effects.
There is a slight difference in my implementation to the function in this paper. The one mentioned in the paper uses a Monoid constraint, while I am using the more general Semigroup. This allows data types that are semigroups but not monoids (all monoids are semigroups). In particular, a non-empty list is a semigroup but not a monoid.
This constraint on the failing value allows the user to automatically accumulate errors as they chain through the Validation values, for example, by keeping them in a non-empty list. I am not going to give example usages of this code in this post because I think it is a great exercise for others and I do not want to spoil it. It is sufficient to say that any usage that type-checks is likely to be a useful example. I may give examples in the future if there is some confusion that needs clarification.
The function can accumulate Validation values using the applicative programming pattern. If all given are successful, you’ll be left with a function that takes all the successful values to a new value, which will be returned as a success. If at least one is not successful, the applicative pattern will begin accumulating with that error value and any future values.
I recommend starting with a simple example such as a Person type with an age :: Int and name :: String with imposed validation rules such as “age must be above 0 and less than 130” and “name must start with a capital letter”. The applied function at the end should be ValidatedInt -> ValidatedString -> Person.
Like I said, if there is any confusion, I’ll expand later. Put the questions in the comments. Enjoy! :)
Here is a Haskell implementation of this:
data Validation e a = Fail e | Success a deriving (Eq, Show)
-- Associative, binary operation (Monoid without identity)
class Semigroup a where
append :: a -> a -> a
(<+>) :: Validation e a -> (a -> b) -> Validation e b
Fail e <+> _ = Fail e
Success a <+> f = Success (f a)
(<*>) :: (Semigroup e) => Validation e a
-> Validation e (a -> b)
-> Validation e b
Fail e1 <*> Fail e2 = Fail (e1 `append` e2)
Fail e1 <*> Success _ = Fail e1
Success _ <*> Fail e2 = Fail e2
Success a <*> Success f = Success (f a)And Scala:
sealed trait Validation[E, A] {
def <+>[B](f: A => B): Validation[E, B] = this match {
case Fail(e) => Fail(e)
case Success(a) => Success(f(a))
}
def <*>[B](f: Validation[E, A => B])(implicit s: Semigroup[E])
: Validation[E, B] = this match {
case Fail(e1) => f match {
case Fail(e2) => Fail(s append (e1, e2))
case Success(_) => Fail(e1)
}
case Success(a) => f match {
case Fail(e2) => Fail(e2)
case Success(f) => Success(f(a))
}
}
}
case class Fail[E, A](e: E) extends Validation[E, A]
case class Success[E, A](a: A) extends Validation[E, A]
// Associative binary operation (Monoid without identity)
case class Semigroup[A](append: (A, A) => A)And now, for the allegedly practical Java. Hold your breath:
// Java pre-amble, sigh.
interface F<X, Y> {
Y apply(X x);
}
// Associative binary operation (Monoid without identity)
interface Semigroup<a> {
A append(A a1, A a2);
}
abstract class Validation<E, A> {
// No algebraic data types in Java. Use a Church encoding (catamorphism).
public abstract <x> X fold(F<E, X> fail, F<A, X> success);
// Construction for fail
public static <E, A> Validation<E, A> fail(final E e) {
return new Validation<E, A>() {
public <x> X fold(final F<E, X> fail, final F<A, X> success) {
return fail.apply(e);
}
};
}
// Construction for success
public static <E, A> Validation<E, A> success(final A a) {
return new Validation<E, A>() {
public <x> X fold(final F<E, X> fail, final F<A, X> success) {
return success.apply(a);
}
};
}
// <+>
public <b> Validation<E, B> map(final F<A, B> f) {
return new Validation<E, B>() {
public <x> X fold(final F<E, X> fail, final F<B, X> success) {
return Validation.this.fold(fail, new F<A, X>() {
public X apply(final A a) {
return success.apply(f.apply(a));
}
});
}
};
}
// <*>
public <b> Validation<E, B> applicativate(
final Validation<E, F<A, B>> f,
final Semigroup<e> s /* no implicits or type-classes in Java */) {
return Validation.this.fold(new F<E, Validation<E, B>>() {
public Validation<E, B> apply(final E e1) {
return f.fold(new F<E, Validation<E, B>>() {
public Validation<E, B> apply(final E e2) {
// case (Fail(e1), Fail(e2))
return Validation.fail(s.append(e1, e2));
}
}, new F<F<A, B>, Validation<E, B>>() {
public Validation<E, B> apply(final F<A, B> f) {
// case (Fail(e1), Success(f))
return Validation.fail(e1);
}
});
}
}, new F<A, Validation<E, B>>() {
public Validation<E, B> apply(final A a) {
return f.fold(new F<E, Validation<E, B>>() {
public Validation<E, B> apply(final E e2) {
// case (Success(a), Fail(e2))
return Validation.fail(e2);
}
}, new F<F<A, B>, Validation<E, B>>() {
public Validation<E, B> apply(final F<A, B> f) {
// case (Success(a), Success(f))
return Validation.success(f.apply(a));
}
});
}
});
}
}There seems to be quite a lot of misunderstanding of Linq. I am not sure how widespread this misunderstanding is, but if I can be persuaded that my selection sample extrapolates accurately, I might consider expanding on this fact:
Linq has nothing to do with SQL or enumerable lists. Nothing and also, not a single thing.
If this is contentious, please let me know and I will endeavour to do something about it (I already have, so I’ll just refer on to begin with).
interface Lam<X, Y> {
Y apply(X x);
}
// http://en.wikipedia.org/wiki/SKI_combinator_calculus
class SKI {
public static <A, B, C> Lam<Lam<A, Lam<B, C>>, Lam<Lam<A, B>, Lam<A, C>>> s() {
return new Lam<Lam<A, Lam<B, C>>, Lam<Lam<A, B>, Lam<A, C>>>() {
public Lam<Lam<A, B>, Lam<A, C>> apply(final Lam<A, Lam<B, C>> f) {
return new Lam<Lam<A, B>, Lam<A, C>>() {
public Lam<A, C> apply(final Lam<A, B> g) {
return new Lam<A, C>() {
public C apply(final A a) {
return f.apply(a).apply(g.apply(a));
}
};
}
};
}
};
}
public static <A, B> Lam<A, Lam<B, A>> k() {
return new Lam<A, Lam<B, A>>() {
public Lam<B, A> apply(final A a) {
return new Lam<B, A>() {
public A apply(final B b) {
return a;
}
};
}
};
}
public static <a> Lam<A, A> i() {
return SKI.<A, Lam<A, A>, A>s().apply(SKI.<A, Lam<A, A>>k()).apply(SKI.<A, A>k());
}
}A result of a discussion in the #scala IRC channel.
Write a minimum function that works on Array[String] and List[Int]. (see error("todo"))
trait Foldable[-F[_]] {
def foldl[A, B](f: (A, B) => A, a: A, as: F[B]): A
def reducel[A](f: (A, A) => A, as: F[A]): Option[A] = foldl[Option[A], A]((a1, a2) =>
Some(a1 match {
case None => a2
case Some(x) => f(a2, x)
}), None, as)
}
object Foldable {
val ListFoldable = new Foldable[List] {
def foldl[A, B](f: (A, B) => A, a: A, as: List[B]) =
as.foldLeft(a)(f)
}
val ArrayFoldable = new Foldable[Array] {
def foldl[A, B](f: (A, B) => A, a: A, as: Array[B]) =
as.foldLeft(a)(f)
}
}
sealed trait Ordering
case object LT extends Ordering
case object EQ extends Ordering
case object GT extends Ordering
// contra
trait Order[A] {
def compare(a1: A, a2: A): Ordering
def min(a1: A, a2: A) =
if(compare(a1, a2) == LT) a1 else a2
}
object Order {
def order[A](f: (A, A) => Ordering): Order[A] = new Order[A] {
def compare(a1: A, a2: A) = f(a1, a2)
}
val IntOrder = order[Int]((a1, a2) =>
if(a1 > a2) GT
else if(a1 < a2) LT
else EQ)
val StringOrder = order[String]((a1, a2) =>
if(a1 > a2) GT
else if(a1 < a2) LT
else EQ)
}
object Main {
import Foldable._
import Order._
def minimum[F[_], A](as: F[A], order: Order[A], fold: Foldable[F]) =
// Zm9sZC5yZWR1Y2VsW0FdKChhLCBiKSA9PiBvcmRlci5taW4oYSwgYiksIGFzKQ==
error("todo")
def main(args: Array[String]) {
val i = minimum(args, StringOrder, ArrayFoldable)
println(i)
val j = minimum(List(5, 8, 2, 9), IntOrder, ListFoldable)
println(j)
}
}Includes a number of bug fixes and an immutable 2-3 finger tree for sequences supporting access to the ends in amortized O(1) time.
// Simulate Higher-Order Functions.
// A lambda function is any implementation of this interface.
interface Lambda<X, Y> {
Y apply(X x);
}
// What is a covariant functor?
// It is any implementation of this interface.
// All implementations must also satisfy:
// * The law of identity
// * The law of composition
// (but let's brush that to the side)
interface Functor<f> {
<A, B> F<b> fmap(F<a> a, Lambda<A, B> f);
}
import java.util.LinkedList;
// Here is the functor for Java's LinkedList.
// It maps a function across each element of the list and returns a new one.
// (trust me, it satisfies the two laws).
class LinkedListFunctor implements Functor<linkedlist> {
public <A, B> LinkedList<b> fmap(final LinkedList<a> a, final Lambda<A, B> f) {
final LinkedList<b> r = new LinkedList<b>();
for(final A x : a)
r.append(f.apply(x));
return r;
}
}
// Here is a trivial Java data type.
// It happens to be a covariant functor.
// Let's witness its instance...
interface IntConverter<a> {
A convert(int i);
}
// The Functor instance for the IntConverter.
class IntConverterFunctor implements Functor<intconverter> {
public <A, B> IntConverter<b> fmap(final IntConverter<a> a, final Lambda<A, B> f) {
return new IntConverter<b>() {
public B convert(final int i) {
return f.apply(a.convert(i));
}
};
}
}
// So why do we care?
// Because it prevents an enormous (*enormous*, *ENORMOUS!*)
// amount of otherwise needless repetition.
class FunctorX {
// Gives rise to:
// LinkedList<Lambda<A, B>> => A => LinkedList<b>
// IntConverter<Lambda<A, B>> => A => IntConverter<b>
// ...
// F<Lambda<A, B>> => A => F<b> (for many values of F)
public static <A, B, F> F<b> fapply(final Functor<f> f, final F<Lambda<A, B>> lam, final A a) {
return f.fmap(lam, new Lambda<Lambda<A, B>, B>() {
public B apply(final Lambda<A, B> z) {
return z.apply(a);
}
});
}
// ... etcetra.
}
// It turns a linear amount of code into a constant amount of code.
// Similarly a sort function that runs on lists of
// any type (provided a comparator) alleviates the need for linear
// amounts of code (a sort function for each possible list element type).I have blocked the msnbot and yahoo! web spiders from indexing this site (and all others at this IP address). They choke up the network with distributed multiple connections. Pretty silly/primitive technique of indexing a web site.
Today I was asked what Haskell’s main feature is. The answer is its non-strict evaluation.
Java is a strictly evaluated language. Consider this Java program:
class C {
static String i() {
throw new Error("boo!");
}
static <a> int f(A a) {
return 3;
}
public static void main(String[] args) {
int k = f(i());
System.out.println(k);
}
}The program fails with a runtime error.
Consider this (otherwise equivalent) Haskell program:
i = error "boo!"
f a = 3
main = let k = f i
in print kThe program prints 3 and does not fail like the Java program. This is a key property of Haskell with very far reaching implications. One of those implications is that Haskell is a pure language. There are many more implications, particularly with respect to the compositional properties of programs.
Haskell’s evaluation model and its implications is perhaps its most widely misunderstood feature. While the benefits are (enormously) enormous, they are far too deep to consider writing a short article about.
interface Pair<A, B> {
A first();
B second();
}
class Pairs {
public static <A, B> Pair<A, B> pair(final A a, final B b) {
return new Pair<A, B>() {
public A first() { return a; }
public B second() { return b; }
};
}
}
interface State<S, A> {
Pair<S, A> run(S s);
}
interface Function<X, Y> {
Y apply(X x);
}
class States {
// State<S, _> is a covariant functor
public static <S, A, B> State<S, B> map(final State<S, A> s, final Function<A, B> f) {
return new State<S, B>() {
public Pair<S, B> run(final S k) {
final Pair<S, A> p = s.run(k);
return Pairs.pair(p.first(), f.apply(p.second()));
}
};
}
// // State<S, _> is a monad
public static <S, A, B> State<S, B> bind(final State<S, A> s, final Function<A, State<S, B>> f) {
return new State<S, B>() {
public Pair<S, B> run(final S k) {
final Pair<S, A> p = s.run(k);
return f.apply(p.second()).run(p.first());
}
};
}
}Haskell is a pure lazy programming language. The laziness of Haskell allows certain performance improvements without sacrificing compositional program properties. I have recently written parsers for XML map data formats that allow a user to “read a data file into a collection of immutable objects.” If I told you I used the parser library to “read in” a 140GB map data file and you’re not familiar with a lazy language, you might have asked how I did this within the constraints of memory requirements. Easy of course; I used a lazy language. The implications of a lazy (and therefore, pure) language are widely misunderstood, so I say “easy” wishing it really was easy for all people, but I know it isn’t (keep practicing!).
HXT is a parsing library for XML that is based on Hughes’ arrows and allows a user to piece together their own specific XML parser. I used it to parse the GPS Exchange (GPX) and OpenStreetMap (OSM) data formats.
Here are some example uses of parsing GPX files and here are examples parsing OSM files. My favourite is a very simple example (there are more complex ones) that removes waypoints from a GPX file. This question (how to remove waypoints from gpx?) was asked on the OSM mailing list quite a while ago; questions like these partially inspired me to write these libraries.
import Data.Geo.GPX
removeWpts :: FilePath -> FilePath -> IO ()
removeWpts = flip interactGpx (usingWpts (const []))The implementation is very simple. The interactGpx function takes two file names and a function that transforms a Gpx data structure to a new Gpx. The interactGpx function reads in the first given file name to a Gpx, executes the given function to produce a new Gpx, then writes the result to the other given file name.
interactGpx :: FilePath -> (Gpx -> Gpx) -> FilePath -> IO ()The usingWpts function takes a function that transforms a list of waypoints to a new list of waypoints and a Gpx value and returns a new Gpx value with the waypoints transformed.
usingWpts :: ([WptType] -> [WptType]) -> Gpx -> GpxOf course, since we want to remove all waypoints, we ignore the given list of waypoints and return an empty list (const []). Pretty neat I reckon!
You can get either of these libraries from hackage:
Here is each of their home page:
Hello everyone,
Many of you know I have been battling health problems for the last 2 years subsequent to a sporting injury. After a total of six surgical procedures, my most recent about 3 weeks ago, I am glad to be almost completely cured. Today I lodged a formal complaint to the Medical Health Board of Queensland against six doctors (coincidentally, the same number of operations – there were a total of 19 doctors mentioned).
As a result of the aforementioned, I haven’t written in a while, so I plan to return to my usual from now on.
I thought I’d write a little about a pervasive problem on the Scala mailing lists. Specifically, the misunderstanding of the purpose of static typing. Of course, there will always be lots of myths and proponents willing to ensure their survival, however, I am a strong believer that education is the only means by which we can advance the software development industry, despite the task often appearing insurmountable (ala Scala mailing list).
Some discussions recently on the Scala mailing list include the relationship between scala.Option data type and null and another discussion about documentation and types that are once-inhabited such as forall a b c. (a -> b) -> (b -> c) -> a -> c
I thought I’d propose a small piece of code and leave any potential insights unstated so as not to destroy anything for the observer. There is a Haskell version toward the end.
I propose the following data type:
trait MyOption[+A] {
// single abstract method
def cata[X](some: A => X, none: => X): X
}Astute observers will notice that the cata method is similar to a combination of the map and getOrElse methods on scala.Option. This topic has also arisen on the Scala mailing list in the past. In other words, I could have written this:
trait MyOption[+A] {
// two abstract methods
def map[X](f: A => X): MyOption[X]
def getOrElse[AA >: A](a: => AA): AA
}…and I’d have a data structure that is exactly the same as the previous one. What may not be obvious is that MyOption is also exactly the same as scala.Option. The correct term for “exactly the same” is isomorphic. Yes, this is despite not using case classes or subclasses – coincidentally, another area where much mythology is prevalent.
I could also write construction functions that are akin to scala.None and scala.Some:
object MyOption {
def none[A] = new MyOption[A] {
def cata[X](s: A => X, n: => X) = n
}
def some[A](a: A) = new MyOption[A] {
def cata[X](s: A => X, n: => X) = s(a)
}
}As an exercise, I propose filling out the Option API, however, using the single abstract method cata and the none/some constructor functions for additional convenience. I promise you it can be done and that anything scala.Option can do, MyOption can do also (and vice versa), since they are isomorphic.
trait MyOption[+A] {
// single abstract method
def cata[X](some: A => X, none: => X): X
def map[B](f: A => B): MyOption[B] = error("todo")
def flatMap[B](f: A => MyOption[B]): MyOption[B] = error("todo")
def getOrElse[AA >: A](e: => AA): AA = error("todo")
def filter(p: A => Boolean): MyOption[A] = error("todo")
def foreach(f: A => Unit): Unit = error("todo")
def isDefined: Boolean = error("todo")
def isEmpty: Boolean = error("todo")
// WARNING: not defined for None
def get: A = error("todo")
def orElse[AA >: A](o: MyOption[AA]): MyOption[AA] = error("todo")
def toLeft[X](right: => X): Either[A, X] = error("todo")
def toRight[X](left: => X): Either[X, A] = error("todo")
def toList: List[A] = error("todo")
def iterator: Iterator[A] = error("todo")
}
object MyOption {
def none[A] = new MyOption[A] {
def cata[X](s: A => X, n: => X) = n
}
def some[A](a: A) = new MyOption[A] {
def cata[X](s: A => X, n: => X) = s(a)
}
}If you get stuck, the answer is base-64 encoded below, however, I encourage you to follow the types and to the extent that there may be ambiguity, follow the existing Scala API specification for scala.Option. If need be, please ask questions. Best of luck!
dHJhaXQgTXlPcHRpb25bK0FdIHsKICAvLyBzaW5nbGUgYWJzdHJhY3QgbWV0aG9kCiAgZGVmIGNh
dGFbWF0oc29tZTogQSA9PiBYLCBub25lOiA9PiBYKTogWAoKICBpbXBvcnQgTXlPcHRpb24uXwoK
ICBkZWYgbWFwW0JdKGY6IEEgPT4gQik6IE15T3B0aW9uW0JdID0gY2F0YShmIGFuZFRoZW4gc29t
ZSwgbm9uZSkKCiAgLy8gQWxzbwogIC8vIGRlZiBtYXBbQl0oZjogQSA9PiBCKTogTXlPcHRpb25b
Ql0gPSBmbGF0TWFwKGYgYW5kVGhlbiBzb21lKQoKICBkZWYgZmxhdE1hcFtCXShmOiBBID0+IE15
T3B0aW9uW0JdKTogTXlPcHRpb25bQl0gPSBjYXRhKGYsIG5vbmUpCgogIGRlZiBnZXRPckVsc2Vb
QUEgPjogQV0oZTogPT4gQUEpOiBBQSA9IGNhdGEocyA9PiBzLCBlKQoKICBkZWYgZmlsdGVyKHA6
IEEgPT4gQm9vbGVhbik6IE15T3B0aW9uW0FdID0gY2F0YShhID0+IGlmKHAoYSkpIHNvbWUoYSkg
ZWxzZSBub25lLCBub25lKQoKICBkZWYgZm9yZWFjaChmOiBBID0+IFVuaXQpOiBVbml0ID0gY2F0
YShmLCAoKSkKCiAgZGVmIGlzRGVmaW5lZDogQm9vbGVhbiA9IGNhdGEoXyA9PiB0cnVlLCBmYWxz
ZSkKCiAgZGVmIGlzRW1wdHk6IEJvb2xlYW4gPSBjYXRhKF8gPT4gZmFsc2UsIHRydWUpCgogIC8v
IFdBUk5JTkc6IG5vdCBkZWZpbmVkIGZvciBOb25lCiAgZGVmIGdldDogQSA9IGNhdGEoYSA9PiBh
LCBlcnJvcigiTm9uZS5nZXQiKSkKCiAgZGVmIG9yRWxzZVtBQSA+OiBBXShvOiBNeU9wdGlvbltB
QV0pOiBNeU9wdGlvbltBQV0gPSBjYXRhKF8gPT4gdGhpcywgbykKCiAgZGVmIHRvTGVmdFtYXShy
aWdodDogPT4gWCk6IEVpdGhlcltBLCBYXSA9IGNhdGEoTGVmdChfKSwgUmlnaHQocmlnaHQpKQoK
ICBkZWYgdG9SaWdodFtYXShsZWZ0OiA9PiBYKTogRWl0aGVyW1gsIEFdID0gY2F0YShSaWdodChf
KSwgTGVmdChsZWZ0KSkKCiAgZGVmIHRvTGlzdDogTGlzdFtBXSA9IGNhdGEoTGlzdChfKSwgTmls
KQoKICBkZWYgaXRlcmF0b3I6IEl0ZXJhdG9yW0FdID0gY2F0YShJdGVyYXRvci5zaW5nbGUoXyks
IEl0ZXJhdG9yLmVtcHR5KQp9CgpvYmplY3QgTXlPcHRpb24gewogIGRlZiBub25lW0FdID0gbmV3
IE15T3B0aW9uW0FdIHsKICAgIGRlZiBjYXRhW1hdKHM6IEEgPT4gWCwgbjogPT4gWCkgPSBuCiAg
fQoKICBkZWYgc29tZVtBXShhOiBBKSA9IG5ldyBNeU9wdGlvbltBXSB7CiAgICBkZWYgY2F0YVtY
XShzOiBBID0+IFgsIG46ID0+IFgpID0gcyhhKQogIH0KfQoKFor Haskell users:
{-# LANGUAGE RankNTypes #-}
-- Data.Maybe
newtype Option a = Option { cata :: forall x. (a -> x) -> x -> x }
-- Just
some :: a -> Option a
some a = Option (\s _ -> s a)
-- Nothing
none :: Option a
none = Option (const id)
-- fmap
map' :: (a -> b) -> Option a -> Option b
map' f m = error "todo"
-- (>>=)
flatMap :: (a -> Option b) -> Option a -> Option b
flatMap f m = error "todo"
-- fromMaybe
getOrElse :: Option a -> a -> a
getOrElse = error "todo"
filter :: Option a -> (a -> Bool) -> Option a
filter m p = error "todo"
-- mapM_
foreach :: Option a -> (a -> IO ()) -> IO ()
foreach m f = error "todo"
-- isJust
isDefined :: Option a -> Bool
isDefined m = error "todo"
-- isNothing
isEmpty :: Option a -> Bool
isEmpty m = error "todo"
-- WARNING: not defined for None
-- fromJust
get :: Option a -> a
get m = error "todo"
-- mplus
orElse :: Option a -> Option a -> Option a
orElse m n = error "todo"
toLeft :: Option a -> x -> Either a x
toLeft m x = error "todo"
toRight :: Option a -> x -> Either x a
toRight m x = error "todo"
-- maybeToList
toList :: Option a -> [a]
toList m = error "todo"
iterator = error "bzzt. This is Haskell silly."ey0jIExBTkdVQUdFIFJhbmtOVHlwZXMgIy19CgotLSBEYXRhLk1heWJlCm5ld3R5cGUgT3B0aW9u
IGEgPSBPcHRpb24geyBjYXRhIDo6IGZvcmFsbCB4LiAoYSAtPiB4KSAtPiB4IC0+IHggfQoKLS0g
SnVzdApzb21lIDo6IGEgLT4gT3B0aW9uIGEKc29tZSBhID0gT3B0aW9uIChccyBfIC0+IHMgYSkK
Ci0tIE5vdGhpbmcKbm9uZSA6OiBPcHRpb24gYQpub25lID0gT3B0aW9uIChjb25zdCBpZCkKCi0t
IGZtYXAKbWFwJyA6OiAoYSAtPiBiKSAtPiBPcHRpb24gYSAtPiBPcHRpb24gYgptYXAnIGYgbSA9
IGNhdGEgbSAoc29tZSAuIGYpIG5vbmUKCi0tICg+Pj0pCmZsYXRNYXAgOjogKGEgLT4gT3B0aW9u
IGIpIC0+IE9wdGlvbiBhIC0+IE9wdGlvbiBiCmZsYXRNYXAgZiBtID0gY2F0YSBtIGYgbm9uZQoK
LS0gZnJvbU1heWJlCmdldE9yRWxzZSA6OiBPcHRpb24gYSAtPiBhIC0+IGEKZ2V0T3JFbHNlID0g
ZmxpcCBjYXRhIGlkCgpmaWx0ZXIgOjogT3B0aW9uIGEgLT4gKGEgLT4gQm9vbCkgLT4gT3B0aW9u
IGEKZmlsdGVyIG0gcCA9IGNhdGEgbSAoXGEgLT4gaWYgcChhKSB0aGVuIHNvbWUgYSBlbHNlIG5v
bmUpIG5vbmUKCi0tIG1hcE1fCmZvcmVhY2ggOjogT3B0aW9uIGEgLT4gKGEgLT4gSU8gKCkpIC0+
IElPICgpCmZvcmVhY2ggbSBmID0gY2F0YSBtIGYgKHJldHVybiAoKSkKCi0tIGlzSnVzdAppc0Rl
ZmluZWQgOjogT3B0aW9uIGEgLT4gQm9vbAppc0RlZmluZWQgbSA9IGNhdGEgbSAoY29uc3QgVHJ1
ZSkgRmFsc2UKCi0tIGlzTm90aGluZwppc0VtcHR5IDo6IE9wdGlvbiBhIC0+IEJvb2wKaXNFbXB0
eSBtID0gY2F0YSBtIChjb25zdCBGYWxzZSkgVHJ1ZQoKLS0gV0FSTklORzogbm90IGRlZmluZWQg
Zm9yIE5vbmUKLS0gZnJvbUp1c3QKZ2V0IDo6IE9wdGlvbiBhIC0+IGEKZ2V0IG0gPSBjYXRhIG0g
aWQgKGVycm9yICJOb25lLmdldCIpCgotLSBtcGx1cwpvckVsc2UgOjogT3B0aW9uIGEgLT4gT3B0
aW9uIGEgLT4gT3B0aW9uIGEKb3JFbHNlIG0gbiA9IGNhdGEgbSAoY29uc3QgbSkgbgoKdG9MZWZ0
IDo6IE9wdGlvbiBhIC0+IHggLT4gRWl0aGVyIGEgeAp0b0xlZnQgbSB4ID0gY2F0YSBtIExlZnQg
KFJpZ2h0IHgpCgp0b1JpZ2h0IDo6IE9wdGlvbiBhIC0+IHggLT4gRWl0aGVyIHggYQp0b1JpZ2h0
IG0geCA9IGNhdGEgbSBSaWdodCAoTGVmdCB4KQoKLS0gbWF5YmVUb0xpc3QKdG9MaXN0IDo6IE9w
dGlvbiBhIC0+IFthXQp0b0xpc3QgbSA9IGNhdGEgbSAoOltdKSBbXQoKaXRlcmF0b3IgPSBlcnJv
ciAiYnp6dC4gVGhpcyBpcyBIYXNrZWxsIHNpbGx5LiIKFrom http://aperiodic.net/phil/scala/s-99/.
object NinetyNine {
// P01
def last[A](as: List[A]): A = as match {
case Nil => error("last on empty list")
case List(x) => x
case _ :: xs => last(xs)
}
// P02
def penultimate[A](as: List[A]): A = as match {
case x :: _ :: Nil => x
case _ => penultimate(as.tail)
}
// P03
def nth[A](n: Int, as: List[A]): A = as match {
case x :: _ if n == 0 => x
case _ => nth(n - 1, as.tail)
}
// P04
def length[A](as: List[A]) = (0 /: as)((a, _) => a + 1)
// P05
def reverse[A](as: List[A]) = (List[A]() /: as)((a, b) => b :: a)
// P06
def isPalindrome[A](as: List[A]) = as == reverse(as)
// P07
def flatten(as: Any*): List[Any] = as flatMap {
case (ns: List[Any]) => flatten(ns: _*)
case (n: Any) => List(n)
} toList
// List is missing a group method
implicit def Group[A](as: List[A]): { def group: List[List[A]] } = new {
def group = as match {
case Nil => Nil
case x :: xs => {
val (a, b) = xs.span(_ == x)
(x :: a) :: Group(b).group
}
}
}
// P08
def compress[A](as: List[A]) = as.group map (_.head)
def compress2[A](as: List[A]): List[A] = as match {
case Nil => Nil
case x :: xs => x :: compress(xs.dropWhile(_ == x))
}
// P09
def pack[A] = (_: List[A]).group
// P10
def encode[A](as: List[A]) = pack(as) map (k => (k.length, k.head))
// P11
// ick
def encodeModified[A](as: List[A]) = pack(as) map (k => {
val l = k.length
val h = k.head
if(l == 1) h else (l, h)
})
// P12
// ick
def decodeModified(as: List[_]) = as flatMap {
case (n: Int, s) => Stream.make(n, s)
case s => List(s)
}
// P13
// WTF?
def encode_direct[A] = (_: List[A]).group map (k => (k.length, k.head))
// P14
def duplicate[A] = (_: List[A]) flatMap (k => List(k, k))
// P15
def duplicateN[A](n: Int, as: List[A]) = as flatMap (k => Stream.make(n, k))
// P16
def drop[A](n: Int, as: List[A]) = as.zipWithIndex filter { case (_, x) => x % n != 2 } map (_._1)
// P17
def split[A](n: Int, as: List[A]) = (as take n, as drop n)
// P18
def slice[A](x: Int, y: Int, as: List[A]) = as drop x take (y - x)
// P19
def rotate[A](n: Int, as: List[A]): List[A] =
if(n < 0) rotate(as.length + n, as)
else (as drop n) ::: (as take n)
// P20
def remove_at[A](n: Int, as: List[A]) = {
val (k, Some(z)) = as.zipWithIndex.foldRight[(List[A], Option[A])]((Nil, None)) { case ((a, x), (t, s)) => if(n == x) (t, Some(a)) else (a :: t, s) }
(k, z)
}
// P21
def insert_at[A](a: A, n: Int, as: List[A]) = {
val (x, y) = as splitAt n
x ::: a :: y
}
// another missing library function
implicit def Unfold[A](a: A): { def unfold[B](f: A => Option[(B, A)]): List[B] } = new {
def unfold[B](f: A => Option[(B, A)]) = f(a) match {
case None => Nil
case Some((b, z)) => b :: (Unfold(z) unfold f)
}
}
// P22
def range[A](x: Int, y: Int) = x unfold (a => if(a > y) None else Some(a, a + 1))
def main(args: Array[String]) {
val ps = List(
last(List(1, 1, 2, 3, 5, 8)), // P01
penultimate(List(1, 1, 2, 3, 5, 8)), // P02
nth(2, List(1, 1, 2, 3, 5, 8)), // P03
length(List(1, 1, 2, 3, 5, 8)), // P04
reverse(List(1, 1, 2, 3, 5, 8)), // P05
isPalindrome(List(1, 2, 3, 2, 1)), // P06
flatten(List(1, 1), 2, List(3, List(5, 8))), // P07
compress(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e)), // P08
pack(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e)), // P09
encode(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e)), // P10
encodeModified(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e)), // P11
decodeModified(List((4, 'a), 'b, (2, 'c), (2, 'a), 'd, (4, 'e))), // P12
encode_direct(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e)), // P13
duplicate(List('a, 'b, 'c, 'c, 'd)), // P14
duplicateN(3, List('a, 'b, 'c, 'c, 'd)), // P15
drop(3, List('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k)), // P16
split(3, List('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k)), // P17
slice(3, 7, List('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k)), // P18
(rotate(3, List('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k)), rotate(-2, List('a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k))), // P19
remove_at(1, List('a, 'b, 'c, 'd)), // P20
insert_at('new, 1, List('a, 'b, 'c, 'd)), // P21
range(4, 9), // P22
)
ps.zipWithIndex foreach { case (p, n) => println("P" + (n + 1) + ": " + p) }
}
}I was recently working on a software project where the client would consult one organisation then that organisation would consult through to my organisation and eventually to me. Unfortunately, the organisation with direct contact to the client does not have very much skill in understanding computer programming problems, the notion of software reusability and decomposition and generally advising the client in such a way to ensure that their interests and expectations are met. This is unfortunate, but also incredibly common (dare I say it, so-called “enterprise” programmers).
A consequence of this debacle is that the software project is highly unlikely to meet the client’s expectation at all or in a timely fashion. Furthermore, I am likely to be asked to accept responsibility for this failure. This is despite my insistence that “using Scala and functional programming is not a panacea, especially when foolish demands are made of me” and various other protests of varying nature.
I used to have to deal with this kind of ineptitude when I was at IBM and I had some very rigorous methods for eschewing the responsibility for poor decisions by those who (I grit my teeth, but it must be said) are incompetent-but-unaware-of-it, while still achieving what was required of me. Such opaqueness does not exist in this case and I’d prefer to produce a useful and timely solution for the client with skilled consulting and the advanced programming techniques that are available.
But I can’t and I’ll be paying the price in the end.
How do others manage this scenario?
I sometimes watch the SBS television station – the content is generally of a higher standard than commercial stations with a greater display of intellectual rigour.
However, there is a Ticketek advertisement on this station with a caption, “What do you think your doing?”.
Ugh.
I once wrote about the mapping of tracks, campgrounds and points of interest in Mount Mee State Forest. Since I have been trapped in my house for many months due to injury, I have entered all my mapping data into OpenStreetMap including Mount Mee State Forest.
Here is a link to the PotLatch map of Mount Mee, however, I much prefer JOSM for entering map data – a surprisingly usable and relatively bug-free Java application (no really!).
If you have track logs – particularly in GPX format – and you’re willing to donate them, I’d be happy to enter them in or use them to tighten up some of the tracks already entered.
New for Functional Java 2.19:
Comonadic operations on Stream, Tree and other data types
Database monad (java.sql.Connection as a functor)
Natural Number data type
The Constant Arrow ($)
Immutable Tree Map
A parallel quick-sort using Functional Java actors
much more
I want you to imagine a scenario for me.
Did you know that carrying a Tiger’s Eye crystal provides protection and clearer thought? Yeah OK I agree, all that crystal healing stuff is just silly nonsense that essentially exists to provide a placebo effect. This doesn’t stop some people from genuinely believing in the healing properties of crystals of course – and they are certainly being exposed to a bias of confirmation. This is because a critical failure of rational faculties has occurred somehow – you and I see straight through it; it’s obviously nonsense! But they seek peer reinforcement for their mistake and have a hard time understanding what it is like to not believe in the healing properties of crystals.
If it is so blatantly false, then why do some apparently intellectually-equipped people swear by it?
Now suppose you were invited to be healed by a crystal healer and you decline because you have other relevant tasks to achieve. What would you say when asked why the declination? You wouldn’t want to insult the questioner – that they believe such a ridiculous proposition doesn’t compel you to simply insult their person, however, if you were to answer the question honestly, they would take offence. You’re caught in a pickle now, so what then? Dishonesty? Appeasing their fantasy?
Would you answer with a question, “I don’t believe crystal healing is effective, because there is no empirical data to suggest it is so. Can you show me otherwise?” to which they respond, “Sure! We use a process of high energy physics photography to derive our scientific conclusions.” So what now? They just provide more bunk – again, you and I see straight through it. You can make no progress. The only reasonable conversation you can have is one about how to deduce true facts in general.
But it gets worse, now imagine that the invitation to the crystal healing session requires that you drink frog poison upon entry, because the ancient Egyptians did it to appease the Gods with a small personal sacrifice. In this scenario, 150 people die each year from ingestion of frog poison, but the crystal healers put this down to anger from the Gods that must only be appeased further, otherwise it will be 300!
At this point, you now object to attendance on the grounds that it is detrimental to your health. Furthermore, you may even feel a moral obligation toward anybody else who has been coaxed into this form of abuse. You’re in a really big pickle now aren’t you?
This is exactly the pickle I am in when you try to peddle your pseudoscience onto me. I don’t want to insult you, but I don’t want to suffer the adverse effects of your crack-pottery. Furthermore, I don’t want other people, who have been tricked (as you have been), to suffer – I feel compelled to warn them against it. Again, not to offend you (though it might), but because I have a deep sense of empathy for all people, including you.
On the other hand, I could do what a lot of us non-crystal-healers do and be proactive in completely ignoring your existence wherever possible but that doesn’t take away from my sense of empathy.
Much of my work is in Scala or Haskell. Lately, it is mostly in Scala. Sometimes I have the unfortunate imposition to use Java by a false authority. This is where Functional Java is handy – in an attempt to make Java somewhat practical, even if only to a small degree.
JetBrains has granted Functional Java an open source licence to use their IntelliJ IDEA. I recently downloaded the 8.1 version and started working on some of the Scala components of Functional Java.
It is pleasing to have a usable IDE that is easy to install on my 64-bit Linux machine. It is more pleasing that the Scala plugin has all the required fundamental features and few bugs. I also use a 32-bit machine running Linux and it was just as much a breeze to install and use there. Of course, I do not use Compiz on these machines, since it screws up swing applications. I do, however, use xmonad window manager, which boosts productivity quite a lot.
The Scala plugin has the much desired “Go to declaration”, is able to report many compile-time errors – though not all and I expect I push Scala a bit harder than many others in terms of finding quirks in the language. It has many other features – some of which need a bit of work, but many of which are significantly ahead of other IDEs, particularly when it comes to stability.
Thanks JetBrains for making it viable to use advanced programming concepts in a capable programming language.
I’ve had two operations on my right ankle and both have failed to correctly diagnose and address the underlying symptomatic complaints that have existed for over 18 months. I am now aware of what the correct diagnosis is, verifiable with historical and radiographic evidence and repeatable symptomatic observations.
The surgeons are cautious given that I’ve already used up two of my available surgery cookie quota and hesitant to go again. This is despite having an exact pinpoint of where the problem is and published literature of what procedure is required. I simply have no rational explanation for this and, if it weren’t for my discomfort, it would leave me in awe.
The diagnosis is anteromedial osseous impingement of the right ankle visible on CT, verified by a radiologist and repeatable on dorsiflexion. This has come about from repeated trauma and in particular, a grade 3 inversion sprain in July 2007. I require a resection of this excess ossification.
I am asking (begging) my international audience for recommendations of a surgeon who is willing to perform this procedure as soon as possible in any part of the world. I suspect, only because I have no other explanation, that there is some bureaucratic restriction preventing me from making progress with surgeons here.
Suggestions please?
A co-variant binary functor (aka bifunctor) is any type constructor with a kind * -> * -> * that can satisfy identity and composition when mapping on either type variable. A couple of examples of bifunctors in the Scala library are
Tuple2
Either
Note that Function1 is not a bifunctor, evident by the fact that it is contra-variant in its first type variable. It is notable that Tuple2 represents conjunction while Either represents the disjunction of two theorems under the Curry-Howard Isomorphism (Function1 represents implication`).
A bifunctor often combines the two possible mappings into a function called bimap with the signature (Scala-ish syntax):
F[A, B] => (A => C) => (B => D) => F[C, D]Recall that identity and composition laws must satisfy in the implementation.
Consider now an implementation of bimap for both Tuple2 and Either:
trait Bifunctor[F[+_, +_]] {
def bimap[A, B, C, D](fa: F[A, B], f: A => C, g: B => D): F[C, D]
}
object Bifunctor {
implicit def Tuple2Bifunctor = new Bifunctor[Tuple2] {
def bimap[A, B, C, D](fa: (A, B), f: A => C, g: B => D) =
(f(fa._1), g(fa._2))
}
implicit def EitherBifunctor = new Bifunctor[Either] {
def bimap[A, B, C, D](fa: Either[A, B], f: A => C, g: B => D) =
fa match {
case Left(a) => Left(f(a))
case Right(b) => Right(g(b))
}
}
}These implementations are quite easy to understand, but they are not so pretty to use. This is an unfortunate consequence of a number of factors about Scala, including:
Higher-kinds are never inferred
Functions cannot be used in infix position
In Scala, methods that end with a colon (:) can have their arguments swapped when not using dot notation. For example, the following two lines are equivalent:
obj.::(arg)
arg :: objThis is evident when using scala.List and the cons (::) method.
We might wrap up our Bifunctor implementation similarly and create some nice syntax for mapping on the bifunctor. For example, let us define three methods on any Bifunctor value:
<-: for mapping on one side
:-> for mapping on the other side
<-:-> for mapping on both sides
trait BifunctorW[F[+_, +_], A, B] {
val value: F[A, B]
val bifunctor: Bifunctor[F]
def <-:->[C, D](f: A => C, g: B => D) = bifunctor.bimap(value, f, g)
def <-:[C](f: A => C) = bifunctor.bimap(value, f, identity[B])
def :->[D](g: B => D) = bifunctor.bimap(value, identity[A], g)
}
object BifunctorW {
// a somewhat verbose but handy trick
// for partially applying type variables.
def bifunctor[F[+_, +_]] = new BifunctorApply[F] {
def apply[A, B](v: F[A, B])(implicit b: Bifunctor[F]) =
new BifunctorW[F, A, B] {
val value = v
val bifunctor = b
}
}
trait BifunctorApply[F[+_, +_]] {
def apply[A, B](v: F[A, B])(implicit b: Bifunctor[F]): BifunctorW[F, A, B]
}
implicit def Tuple2Bifunctor[A, B](v: (A, B)) =
bifunctor[Tuple2](v)
implicit def Either2Bifunctor[A, B](v: Either[A, B]) =
bifunctor[Either](v)
}So we’ve wrapped a value and its Bifunctor implementation. So how does it look when we use it? Like this!
object Main {
def main(args: Array[String]) {
import BifunctorW._
val x: Either[Int, String] = Left(7)
val y = ("hello", 42)
val f = (n: Int) => n + 1
val g = (s: String) => s.reverse
val h = (s: String) => s.toUpperCase
val i = (n: Int) => n * 2
// Pretty neat eh?
val p = f <-: x :-> g
val q = h <-: y :-> i
// $ scala Main
// Left(8)
// (HELLO,84)
println(p)
println(q)
}
}And I think that’s an elegant use of a sometimes baroque (when trying for advanced concepts) language :)
I decided to play around with arrows and Scala to see how far I could get. I remember vividly the effort required to get a Monad abstraction for Scalaz to work and be useful all at once with so many competing tensions (e.g. type inferencer, composability, repetition).
I didn’t go so far as to test the usefulness, but I was able to express the Kleisli arrow without too much effort. I wonder if it is a viable addition for Scalaz.
Here it is.
The typical Functor/Monad abstraction. These are required for the Kleisli arrow.
trait Functor[F[+_]] {
def fmap[A, B](fa: F[A], f: A => B): F[B]
}
trait Monad[M[+_]] extends Functor[M] {
def pure[A](a: A): M[A]
def bind[A, B](ma: M[A], f: A => M[B]): M[B]
final def fmap[A, B](fa: M[A], f: A => B) =
bind(fa, (a: A) => pure(f(a)))
}The Kleisli data type and a convenient constructor.
trait Kleisli[M[+_], -A, +B] {
def apply(a: A): M[B]
}
object Kleisli {
def kleisli[M[+_], A, B](f: A => M[B]) = new Kleisli[M, A, B] {
def apply(a: A) = f(a)
}
}The arrow abstraction.
trait Arrow[A[-_, +_]] {
def arrow[B, C](f: B => C): A[B, C]
def compose[B, C, D](a1: A[B, C], a2: A[C, D]): A[B, D]
def first[B, C, D](a: A[B, C]): A[(B, D), (C, D)]
def second[B, C, D](a: A[B, C]): A[(D, B), (D, C)]
}and the clincher…
object Arrow {
val Function1Arrow = new Arrow[Function1] {
def arrow[B, C](f: B => C) = f
def compose[B, C, D](a1: B => C, a2: C => D) =
a2 compose a1
def first[B, C, D](a: B => C) =
(bd: (B, D)) => (a(bd._1), bd._2)
def second[B, C, D](a: B => C) =
(db: (D, B)) => (db._1, a(db._2))
}
def KleisliArrow[M[+_]](implicit m: Monad[M]) =
new Arrow[PartialType[Kleisli, M]#Apply] {
import Kleisli.kleisli
def arrow[B, C](f: B => C) =
kleisli[M, B, C](b => m.pure(f(b)))
def compose[B, C, D](a1: Kleisli[M, B, C], a2: Kleisli[M, C, D]) =
kleisli[M, B, D](b => m.bind(a1(b), (c: C) => a2(c)))
def first[B, C, D](a: Kleisli[M, B, C]) =
kleisli[M, (B, D), (C, D)] { case (b, d) => m.fmap(a(b), (c: C) => (c, d)) }
def second[B, C, D](a: Kleisli[M, B, C]) =
kleisli[M, (D, B), (D, C)]{ case (d, b) => m.fmap(a(b), (c: C) => (d, c)) }
}
}TODO
Write functions across arrows.
Can arrows be made useful within the constraints of Scala?
Here is how a continuation data type might look in Scala:
sealed trait Continuation[R, +A] {
def apply(f: A => R): R
import Continuation.continuation
def map[B](k: A => B) =
continuation[R, B](z => apply(z compose k))
def flatMap[B](k: A => Continuation[R, B]) =
continuation[R, B](z => apply(k(_)(z)))
}Note that there are map and flatMap functions that satisfy the functor and monad laws. Continuation[R, _] is a monad.
Now let’s add some construction functions:
object Continuation {
def continuation[R, A](g: (A => R) => R) = new Continuation[R, A] {
def apply(f: A => R) = g(f)
}
def unit[R] = new {
def apply[A](a: A) = continuation[R, A](f => f(a))
}
def callcc[R, A, B](f: (A => Continuation[R, B]) => Continuation[R, A]) =
continuation[R, A](k => f(a => continuation(x => k(a)))(k))
}The continuation function is a straight-forward construction. The unit function constructs a continuation is such a way as to satisfy the monad laws against the flatMap method. The callcc function (call with current continuation) is to allow “escaping” from the current continuation.
Here is some example client code that squares a number using a continuation (see squarec):
object Square {
import Continuation._
def square(n: Int) = n * n
// Continuation for square
def squarec[R](n: Int) = unit[R](square(n))
// Continuation for effect (Unit) on square.
// This is simply to help the type inferencer by applying a type argument.
def squareE(n: Int) = squarec[Unit](n)
def main(args: Array[String]) {
val k = squareE(args(0).toInt)
k(println)
}
}A slightly more complicated example for modelling exceptions. Let’s divide where the denominator must be 0 or an “exception” is thrown:
object Divide {
import Continuation._
// Division
def div[R](c: String => Continuation[R, Int])
(n: Int, // numerator
d: Int) // denominator
: Continuation[R, Int] =
callcc[R, Int, String](ok =>
callcc[R, String, String](err =>
if(d == 0) err("Denominator 0")
else ok(n / d)
) flatMap c)
def main(args: Array[String]) {
def divError[R] = div[R](error(_)) _
println(divError(7, 3)(x => x))
println(divError(7, 0)(x => x)) // throws error
}
}I used to lecture at university. These days I teach for fun. Sometimes I am asked about controlling effects in a pure programming language such as Haskell by people who are very familiar with Scala’s flatMap method on List type, Option and so on (sadly, it is missing from the most fundamental of all – Function1). I often do this on a white-board and it has been reasonably successful at producing “aha! moments” so maybe it will help you.
Scala includes special syntax for using this method in the form of for-comprehensions. Specifically code like the following…
for(k <- e1;
l <- e2(k);
m <- e3;
n <- e4(k, m))
yield f(k, l, m, n)…is translated into…
e1 flatMap (k =>
e2(k) flatMap (l =>
e3 flatMap (m =>
e4(k, m) map (n =>
f(k, l, m, n)))))Notice the final call to map which is a specialisation of a call to flatMap by taking the unital for the type constructor under consideration. Gobbledy-gook? It’s simple really. Consider Lists:
x map f
// can also be written
x flatMap (z => List(f(z)))That is because x => List(x) is the unit for List. For Option this function is the unit operation: x => Some(x). Try it next time you call map – use flatMap instead plus the unit operation for whatever type constructor you’re using (List, Option, whatever) – you’ll always get the same result. For Function1 the unit operation is x => y => x. I digress.
When I am asked about controlling side-effects I point to this flatMap business first so that I can assume familiarity (simple right?), then I switch to a completely different discussion about say, the following Java program snippet:
T t = e1();
e2(t);
U u = e3(t);
V v = e4(t, u);
return e5(u, v);What I do with this snippet is invent a new programming that has very similar, but still different syntax to Java and I rewrite the program above. I do two things first
The syntax for assignment occurs in reverse
I remove type annotations (like T, U and V)
Here is how the program looks now:
e1() = t;
e2(t);
e3(t) = u;
e4(t, u) = v;
return e5(u, v);Next I replace semi-colons (except the last one) with => and I rename return to unit:
e1() = t =>
e2(t) =>
e3(t) = u =>
e4(t, u) = v =>
unit e5(u, v)Finally, I replace the equals sign with flatMap and I add a special case for the call to e2 which has no return value by calling flatMap but ignoring the parameter to the given function (denoted with an underscore):
e1() flatMap t =>
e2(t) flatMap _ =>
e3(t) flatMap u =>
e4(t, u) flatMap v =>
unit e5(u, v)Since we know that the call to flatMap with unit can be replaced with a call to map let’s do that:
e1() flatMap t =>
e2(t) flatMap _ =>
e3(t) flatMap u =>
e4(t, u) map v =>
e5(u, v)Voila! Have we just turned an imperative program into a pure one just by altering syntax!? Not really – rather, the distinction between imperative and pure is entirely dependent on the colour of your glasses. There is no hard-and-fast divide between one and the other (let that not detract from the huge implications of using one or the other). Importantly, we have seen that we can control side-effects with flatMap.
The flatMap method is at the very essence of a computational model called monads. Note that while we can control side-effects with monads, monads are not always about controlling side-effects! Indeed, when we call flatMap on Option or List we are using monads that have nothing to do with side-effects.
Haskell calls flatMap by a different name >>= and instead of for-comprehensions, Haskell has do-notation.
Pretty simple really isn’t it? :)
Scalaz is no longer on the workingmouse website but is hosted on Google Code at http://code.google.com/p/scalaz/.
If you say “Microsoft Windows = bad” you are almost certainly making a false claim within your own beliefs. Not because Windows is not bad necessarily and not because I might think it is good, but because Windows = bad is likely to give rise to an absurdity within your own beliefs should I interrogate you on the matter. There is a difference. Consider also “Hitler = bad”. If you think that “Windows = bad” and “Hitler = bad” then you also think “Windows = Hitler”. I will expect you don’t believe “Windows = Hitler”.
What you likely intend instead is “Windows ⇒ bad”. You could read this as “Windows implies bad”. Now you are free to believe the following three statements without giving rise to an inconsistency in your belief:
Windows ⇒ bad
Hitler ⇒ bad
Windows ≠ Hitler
Here is the truth table for implication:
P Q P⇒Q 0 0 1 0 1 1 1 0 0 1 1 1
Notice how ⇒ does not commute? Specifically, if you swap the propositions around you might get a different result. Bad ⇒ Windows is not the same as Windows ⇒ Bad – of course. This cannot be said for =. Bad = Windows is the same as Windows = bad.
You might wonder why I care so much. After all, if you said “Windows = bad” I’d know what you meant. But did you know what you meant and is this understanding universal each time you relax your discourse like this?
I have often observed a confusion between equivalence (also often called bi-implication) and implication in general discussion. Indeed, I hypothesise that this tendency to subvert a proposition in this manner is responsible for many failings in humanity’s general faculty of reason. I think we as a species would be better for it if we repair this failure of intellectual discipline (for what gain anyway?).
Therefore, I think that not only is this trivial correction important, but very much so. Thanks for listening.
Inspired by a very important point made by Jamis Buck.
If you use Windows then you have my sympathy but nothing more. However, if you are stupid enough to elect to use Windows then you don’t even have my sympathy.
This attitude – although somewhat stolen – is incredibly vital to maintaining my sanity. If I may replace Windows with other values maintaining the same sentiment:
Java
Maven (I’m looking at you my Functional Java users)
Ruby
Ruby on Rails
Eclipse
The Scala API leaves a lot to be desired. I’m going to pick on a few methods that should appear, but do not, on [scala.Function1](http://www.scala-lang.org/docu/files/api/scala/Function1.html).
They are:
map
flatMap
on
Using some magic with the implicit keyword I can make it appear as if these methods did in fact exist:
sealed trait RichFunction1[-T, +R] {
def apply(t: T): R
import RichFunction1.rich
def map[X](g: R => X) = rich[T, X](g compose (apply(_)))
def flatMap[TT <: T, X](g: R => RichFunction1[TT, X]) =
rich[TT, X](t => g(apply(t))(t))
// The S combinator (SKI)
def <*>[TT <: T, X](f: RichFunction1[TT, R => X]) = (t: TT) => f(t)(apply(t))
// S again, swapped arguments
def <*>:[TT <: T, X](f: RichFunction1[TT, R => X]) = <*>(f)
// map with swapped arguments
def <-:[X](g: R => X) = map(g)
def on[K](f: (R, R) => K, t1: T, t2: T): K = f(apply(t1), apply(t2))
}
object RichFunction1 {
implicit def rich[T, R](f: T => R) = new RichFunction1[T, R] {
def apply(t: T) = f(t)
}
}By having flatMap (and therefore map) this allows you to remove a lot of duplication. This may come at the expense of syntactical noise per Scala, but not always. Suppose you were given a String and you wanted to check if it was equal to one of a few Strings (ignoring case). You could use some trickery with existing methods on List, but I want to keep this example simple, so let us ignore that possibility for now (and accept that I could come up with a sufficient example that such trickery is insufficient).
// For example, suppose this predicate function
def predicate(s1: String) = s1 equalsIgnoreCase (_: String)Here is the repetition
// predicate(s, _) repeats
def f(s: String) = predicate("x")(s) || predicate("y")(s) || predicate("z")(s)But if we have flatMap and map we can use a for-comprehension:
// Taking advantage of flatMap/map
val g = for(a <- predicate("x");
b <- predicate("y");
c <- predicate("z"))
yield a || b || cHere is how that same code looks when expanded:
// Expansion of g
val h = predicate("x") flatMap (a =>
predicate("y") flatMap (b =>
predicate("z") map ((c =>
a || b || c))))How about some fancy stuff with the S combinator (<*>):
val or = Function.curried((_: Boolean) || (_: Boolean) || (_: Boolean))
// Using the S combinator
val i = predicate("z") <*>
(predicate("y") <*>
(predicate("x") map
or))Or with the arguments swapped around:
// Using S with swapped arguments
val j = ((or <-: predicate("x")) <*>: predicate("y")) <*>: predicate("z")Pretty neat eh?
Suppose you wanted to check if the length of one List was less than the length of another. You might be tempted to write x.length < y.length. Notice how _.length repeats? Again I want to keep this example simple so while the solution below is more noisy, there are cases where it is not.
Scala is let down a little by first-class function semantics. We’ll begin with assuming this first-class function value:
val length = (_: List[Int]).lengthThen comparing using length:
val k = length on (_ < _, List(4, 5, 6, 7), List(1, 2, 3))A bit noisier but the repetition is gone. It’s a shame that abstraction comes at a syntactic cost and in some cases it may even be worth that cost. I wish I had the choice.
I work from home now. It rocks :) I also live in a rental property in the warm climate of Brisbane, Australia.
I wish to convert one of the rooms – westward-facing, 3 metres by 3 metres – into my office. I currently work in the main living area under a split system A/C and this has some problems that I want to alleviate.
Below is an image of the only window in this room. It has a single slider 570mm by 1450mm (the pink line) which is fitted with a security screen by pop-rivets. This window faces west and there is drainage outside.
Bedroom Window
What is an appropriate set up for cooling such a room, given that it is a rental property? I have looked at evaporative coolers and portable air conditioners but have been advised against both given our climate. It also appears somewhat difficult to use a portable A/C given the fixed security screen and the need for an external vent – can it me reversibly modified somehow? I find no other appropriate option and am a bit of a deadlock. Advice?
Why Functional Programming Matters paraphrased – a result of a discussion in an IRC channel. Others may find value.
A program may be represented as a function that accepts some input and produces some outputλ This function may be composed of parts; other functions and values.
Suppose any function that exists. I will suppose one that is made of parts A, B, C and D. I might denote this A ∘ B ∘ C ∘ D. Now suppose you desire a function that is made of parts A, B, C and E. Then the effort required for your function should be proportional to the effort required for E alone.
The closer you are to achieving this objective for any function, the closer you are to the essence of (pure) functional programming. This exists independently of the programming language, though programming languages will vary significantly in the degree to which they accommodate this objective.
Imperative programming – specifically the scope of a destructive update – is the anti-thesis of this objective.
An exercise arising from an IRC discussion in #scala:
trait Functor[F[_]] {
def fmap[A, B](fa: F[A], f: A => B): F[B]
}
trait Monad[M[_]] {
def bind[A, B](ma: M[A], f: A => M[B]): M[B]
def pure[A](a: A): M[A]
}
object ObserveFunctorMonad {
def observe[K[_]](m: Monad[K]): Functor[K] = error("your homework")
}I am an avid GPS user and I visit Mount Mee State Forest regularly on my dirt bike (Husqvarna TE450). I encounter queries on forums for the locations of the campgrounds in this forest, so here they are:
Neurum Creek Campground -27.061853° 152.696228° -27°03’42.67" 152°41’46.42"
Archer Campground -27.016317° 152.697767° -27°00’58.74" 152°41’51.96"
You can get to Neurum Creek Campground by taking Sellin Road then turning onto Neurum Creek Road and following it north. Archer Campground can be found by taking Sellin Road then Lovedays Road, however, it is easier to approach from the north side of the forest and head south. Both of these campgrounds require a permit through the Environmental Protection Agency (EPA) or you can book online.
There is another campground called Neurum Creek Bush Retreat but this is a different campground to those two mentioned. It is privately owned and I have personally stayed a weekend there and recommend it, especially if you have children or want a weekend of dirt bike riding (though the operators are understandably strict about noise control) since you can head south into Mount Mee State Forest or head over to Beerburrum State Forest. This campground is even further north of the state forest than the other two (which are situated in the forest boundaries), but is a short ride on gravel to the forest entrance.
Here is a reasonably comprehensive GPX file of Mount Mee State Forest including the two campgrounds and many dirt trails. I’d upload it to OpenStreetMap but I have yet to figure that out.
I use a Garmin 60Cx unit.
I hope this helps ;)
Update: I have uploaded all tracks to OSM See here
Nov 17 15:48:39 <jinok>i hate wasting vertical space declaring vals that i need to initialize outside of a try block so i can clean them up in a finally blockNov 17 15:48:53 <jinok>so i’ve started doing the initialization using lazy vals.
sealed trait Resource[+T] {
val value: T
def close: Unit
def use[X](f: T => X) = try { f(value) } finally { close }
}
import java.io.InputStream
object Resource {
def resource[T](t: T, c: => Unit) = new Resource[T] {
val value = t
def close = c
}
implicit def InputStreamResource(t: InputStream) = resource(t, t.close)
}
object Example {
import Resource._
def main(args: Array[String]) {
val in = new java.io.FileInputStream("/etc/passwd")
// print the first character of /etc/passwd
println(in use (_.read.toChar))
}
}Reader’s exercise: Resource is a functor and monad. Implement the map and flatMap methods. Observe trickiness and ask why?
Re: Comments on http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
For example
Well, okay, but Agile is starting to sound a lot more like religious rhetoric than an engineering practice.
and
Insert compelling argument here. It is a religion.
Agile is not a religion, however, both Agile and religions are non-ideas. Also referred to as the third value of the propositional truth trichotomy, “not even false”, non-terminating computation, the bottom value, unfalsifiable, or if you prefer, outright nonsense. All religions and Agile (and Scrum and REST and SOA and… need I go on?) fall into this broader category. It might be healthy to call this category “religion”, but many observers - at least in my dealings - won’t understand why you have shifted to this consistent definition.
Hitherto Agile and religions exhibit common traits; ill-definition (you know the real Agile or are you a real Muslim?), sub-cultures in conflict (religion implies war), extreme absurdity in contrast to a mild absurdity (an invisible sky daddy watching everything we do, whose son died for sins…), cult leaders able to alter the course of the flock and cognitive dissonance - holding two otherwise immediately apparent logically contradicting positions at once.
I’m happy to hear this pseudo-science is falling - its absence is an improvement for the industry and the quality of software development. However, the concern is that it will be replaced by another non-concept for the scientific-illiterates to sustain their well-intentioned misguidance.
History tells us that its downfall is not an improvement. After all, what was immediately before the current Abrahamic false ideas? The creation of the universe and therefore, the first religions? No, I don’t think so either - I don’t think anybody does :)
I have a couple of whining rants on here about the ineptitude of the IntelliJ IDEA Early Access Program releases and the Scala plugin. It was, at that time, quite unusable, which is fine on its own, but I was concerned by the fact that the number and magnitude of the workarounds was increasing over time.
I am pleased to report that my preliminary use of the recently released IntelliJ IDEA 8.0 and the Scala plugin appears to require significantly less workarounds to the degree that it is now usable. In fact, it is more usable than it has been in a long time.
Myself and at least one other person were initially tricked into believing that there was no Scala plugin available because it was not listed in the Available plugins. There was however, a “Scala Application runner” plugin available. Installing this also installs the Scala plugin.
Unless I am making a judgment too early, I consider IntelliJ IDEA to have redeemed itself from my earlier complaints and I am thankful to the JetBrains team for making it so (with little/no effort on my part).
Interestingly, I note that JetBrains are considering adding automated specification testing and make a reference to ScalaCheck in this discussion. I wonder if they are aware of this alternative (Functional Java) that does the same with a more comprehensive library and also able to be used from standard Java.
Thanks for listening to my whining earlier and thanks to JetBrains for making smooth development with Scala possible :)
Edit: Except this same old bug is still there (it has been there for months) when expanding some source trees (I know I’m not the only one to experience this):
Error during dispatching of java.awt.event.MouseEvent[MOUSE_PRESSED,(118,350),absolute(114,375),button=1,modifiers=Button1,extModifiers=Button1,clickCount=1] on frame0
java.lang.StackOverflowError
at com.intellij.psi.impl.CachedValueImpl.a(CachedValueImpl.java:1)
at com.intellij.psi.impl.CachedValueImpl.a(CachedValueImpl.java:70)
at com.intellij.psi.impl.CachedValueImpl.a(CachedValueImpl.java:3)
at com.intellij.psi.impl.CachedValueImpl.a(CachedValueImpl.java:104)
at com.intellij.psi.impl.CachedValueImpl.getValue(CachedValueImpl.java:41)Scalaz 3.2 includes support for a State data type for the Scala Programming Language. This data type is a monad and thus supports flatMap and can be used in a for-comprehension.
Below I will give a practical demonstration of why you might choose to use the State data type as a monad.
Consider a binary leaf tree data type:
sealed abstract class Tree[+A]
final case class Leaf[A](a: A) extends Tree[A]
final case class Branch[A](left: Tree[A], right: Tree[A]) extends Tree[A]This is pretty simple so far. Now suppose we wanted to map a function across a Tree from left to right where the result depended on the previous result. For this example, consider that we wanted to number each leaf by adding 1 as we traverse left to right (at a given starting value). That is, the result depends on the previous result because we must add 1 to that previous result.
We might implement this by passing in the integer value and returning the pair of the Tree as it is constructed and the integer value as it increments. Such an implementation might look like this:
sealed abstract class Tree[+A] {
def number(seed: Int): (Tree[(A, Int)], Int) = this match {
case Leaf(x) => (Leaf(x, seed), seed + 1)
case Branch(left, right) => left number seed match {
case (l, ls) => {
right number ls match {
case (r, rs) => (Branch(l, r), rs)
}
}
}
}
}This code is pretty messy and it would become even messier with a less trivial example to apply across the Tree.
The State data type is effectively a Function[S, (S, A)] and the monad instance runs across the Function[_, (_, A)] part. That is to say, the flatMap signature looks roughly like this:
trait State[S, A] {
val s: Function[S, (S, A)] // abstract
def flatMap[B](f: A => Function[S, (S, B)]): Function[S, (S, B)]
}You might consider filling out this method signature for fun :)
The flatMap function allows the user to make the state change implicit rather than explicit (and messy!). The State data type includes a few useful methods and functions. I will only use two of those functions below; init, which constructs a State object that has computed the state itself. For example, going with the analogy to Function[S, (S, A)], the init function looks like this: s => (s, s) and so returns a State[S, S]. The second function is modify, which applies a transform the state and it is intended to ignore the computed value (Unit).
Here is our new implementation:
import scalaz.State
import scalaz.State._
def numbers: State[Int, Tree[(A, Int)]] = this match {
case Leaf(x) => for(s <- init[Int];
n <- modify((_: Int) + 1))
yield Leaf((x, s + 1))
case Branch(left, right) => for(l <- left.numbers;
r <- right.numbers)
yield Branch(l, r)
}This is much neater and hides the otherwise explicit recursive application of adding 1 to an integer. Following is a complete source file that can be compiled successfully against Scalaz 3.2 using the latest version of Scala.
sealed abstract class Tree[+A] {
def number(seed: Int): (Tree[(A, Int)], Int) = this match {
case Leaf(x) => (Leaf(x, seed), seed + 1)
case Branch(left, right) => left number seed match {
case (l, ls) => {
right number ls match {
case (r, rs) => (Branch(l, r), rs)
}
}
}
}
import scalaz.State
import scalaz.State._
def numbers: State[Int, Tree[(A, Int)]] = this match {
case Leaf(x) => for(s <- init[Int];
n <- modify((_: Int) + 1))
yield Leaf((x, s + 1))
case Branch(left, right) => for(l <- left.numbers;
r <- right.numbers)
yield Branch(l, r)
}
}
final case class Leaf[A](a: A) extends Tree[A]
final case class Branch[A](left: Tree[A], right: Tree[A]) extends Tree[A]And if you find Haskell easier to read, this might help too. It is a roughly equivalent program using GHC’s built-in State data type.
import Control.Monad.State.Lazy
data Tree a = Leaf a | Branch (Tree a) (Tree a)
number :: Int -> Tree a -> (Tree (a, Int),Int)
number seed (Leaf a) = (Leaf (a, seed), seed + 1)
number seed (Branch left right)
= let (l, ls) = number seed left
(r, rs) = number ls right
in
(Branch l r, rs)
numbers :: Tree a -> State Int (Tree (a, Int))
numbers (Leaf a) = do n <- get
modify (+1)
return (Leaf (a, n))
numbers (Branch l r) = do left <- numbers l
right <- numbers r
return (Branch left right)
initState :: State s s
initState = State (\s -> (s, s))Well done. Keep it up.
Sadly, despite my expressed hopes, in appears the state of Intellij IDEA with Scala is not improving but worsening. This is sad. Each time you start up IDEA you still get a lovely internal error and exception stack trace. But worse, ever since the 8890 EAP build, the application hangs with any reasonably sized Scala project. This is even more sad. A colleague has confirmed this on his Mac, however, we are unable to revert to a usable version since you cannot download older EAP releases.
The suspected trend toward becoming more unusable for Intellij IDEA and Scala is regrettably confirmed. I wish it were not so ):
The Windows Vista upgrade to XP effect perhaps?
So you were once a Java fanboy and now you’ve apostatised to the Ruby cult. Now you believe you hold veritable opinions about “statically typed languages” and “dynamically typed languages”. How wrong you are.
Java is not representative of static type systems, not even a bit. It lacks some of the most basic features of a static type system. It might even be said that its static type system imposes some of the most impractical insanity that could possibly be conceived. Why do I think this? Because I have pushed Java’s static type system to its limits and relative to its peers, it fails miserably. I’ve seen the language inside-out. I used to work on the JDK implementation for a certain corporation (of questionable ethical standards). I even have the spanky Sun Java Programmer/Developer certifications. Yes I have been drowned in Java Jolly Junkie bullshit and revived.
So you use Ruby eh? It allows you to express things that Java was too rigid to allow, right? That doesn’t mean a thing about static type systems, right? RIGHT?
When you use Java and Ruby as the example for static and dynamic type systems, I am reminded of my children who compare the flight of their scrunched up pieces of paper… er highly aerodynamic, radar-resistant aircraft (sorry boys). Hopefully some day they will learn what a wind tunnel is and what it takes to engineer a fighter-aircraft. Will you?
This kind of enthusiasm is to be encouraged – if you are 6 years old – but you are not, so you just look like you are in an adult’s body. No really, you do. This might be fine with you (who am I to judge?), but if it is not, it might help to know What to Know Before Debating Type Systems. Just a thought – there is plenty of other information available should you desire to seek it, just drop me a line.
Here are some tips to get started; static typing and explicit type annotating are two very different things. Don’t use the two notions interchangeably – not even loosely. Dynamically-typed languages do not produce shorter code, this is a myth. In fact, what constitutes shorter code is often misunderstood – certainly by Ruby (and Python, Groovy for that matter) advocates that I have encountered. I’m tempted to dispense with this myth with a challenge, but I’m not sure if I can be bothered (I have a life outside of whinging on my blog you know). It would also fail to do the topic justice. An entire discussion on what constitutes shorter code is in order.
For the love of GADTs, in the meantime, please stop talking nonsense about static and dynamic type systems. It only serves to hurt other potential learners by perpetuating misinformation. Myths spread by repetition – be honest and break the cycle.
I hear this question a lot. Yes it does. Instead of c ? p : q, it is written if(c) p else q.
This may not be preferable. Perhaps you’d like to write it using the same syntax as Java. Sadly, you can’t. This is because : is not a valid identifier. Fear not, | is! Would you settle for this?
c ? p | qThen you’ll need the following code. Notice the call-by-name (=>) annotations on the arguments. This evaluation strategy is required to correctly rewrite Java’s ternary operator. This cannot be done in Java itself.
case class Bool(b: Boolean) {
def ?[X](t: => X) = new {
def |(f: => X) = if(b) t else f
}
}
object Bool {
implicit def BooleanBool(b: Boolean) = Bool(b)
}Here is an example using the new operator that we just defined:
object T {
val condition = true
import Bool._
// yay!
val x = condition ? "yes" | "no"
}Have fun ;)
Project Euler Problem 2 using Functional Java:
import fj.data.Stream;
import fj.P1;
import fj.F2;
import static fj.function.Integers.even;
import static fj.pre.Ord.intOrd;
import static fj.pre.Monoid.intAdditionMonoid;
import static fj.data.Stream.cons;
import static fj.Function.curry;
...
Stream<integer> fibs = new F2<Integer, Integer, Stream<integer>>() {
public Stream<integer> f(final Integer a, final Integer b) {
return cons(a, P1.curry(curry(this).f(b)).f(a + b));
}
}.f(1, 2);
final int problem2 = intAdditionMonoid.sumLeft(fibs.takeWhile(intOrd.isLessThan(1000001)).filter(even).toList());Project Euler Problem 1 using Functional Java:
import static fj.pre.Monoid.intAdditionMonoid;
import static fj.data.List.range;
import fj.F;
...
final int problem1 = intAdditionMonoid.sumLeft(range(0, 1000).filter(new F<Integer, Boolean>() {
public Boolean f(final Integer a) {
return a % 3 == 0 || a % 5 == 0;
}
}));I have been caught out by type-checking code that fails at runtime. It should have failed at compile-time due to a language limitation in structural types – not a logical absurdity in the code itself. Thankfully I have a workaround, but it does provoke persistent hesitance – giving that disgusting feeling as if I were using something as degenerate as, for example, Ruby or even worse (can it get worse?), Groovy. I’ll have to counsel myself on that one.
Nevertheless, I give warning. Here is the bug report. Here is the fun. Observe:
scala> def left[B] = new { def apply[A](a: A): Either[A, B] = Left(a) }
left: [B]java.lang.Object{def apply[A](A): Either[A,B]}
scala> left[String](7)
res6: Either[Int,String] = Left(7)
scala> def left[B] = new { def apply[A](a: A, b: B): Either[A, B] = Left(a) }
left: [B]java.lang.Object{def apply[A](A,B): Either[A,B]}
scala> left(7, "")
res8: Either[Int,java.lang.String] = Left(7)
scala> left[String](7, "")
java.lang.NoSuchMethodException: $anon$1.apply(java.lang.Object, java.lang.String)
at java.lang.Class.getMethod(Class.java:1605)
at .reflMethod$Method1(<console>:6)
at .<init>(<console>:6)
at .<clinit>(<console>)
at RequestResult$.<init>(<console>:3)
at RequestResult$.<clinit>(<console>)
at RequestResult$result(<console>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native ...An update on IntelliJ IDEA + Scala utterly unusable
Delete ~/.IntelliJIdea80 (oh well, I’m so used to specifying my settings over and over anyway).
Start IntelliJ IDEA. Do not open a project
Install the Scala plugin
Open your project
Observe not-useless usability
There are still issues of not being able to open certain source folders (try it and see for yourself scalaz.control in Scalaz trunk)
Other minor annoyances that needn’t be mentioned
I have repeated this twice on different machines (8823). Swapping steps 3 and 4 result in a rapid degeneration of usefulness to the point of absolute uselessness.
Thanks again for listening. I hope the usability trend reverses.
It seems that IntelliJ IDEA 8.0 EAP and its Scala plugin have reached the point of being completely unusable. This is such a shame given that there are no existing viable alternatives (don’t say Eclipse and expect me to keep a straight face). I guess it will be emacs or Kate in the future.
The last few EAP releases crash the IDE when you expand some source trees resulting in a perpetual wait icon. I receive a dialog about submitting the bug and I have done, three times. The last two EAP releases (8823 and 8810) don’t allow me to install the Scala plugin at all. Upon restart, the IDE is unaware that the Scala plugin has even been installed. As a result, I have to use 8664, which my trial is due to expire any time soon.
The IDE constantly gives me false errors (surely it is not difficult to download the Scalaz source and observe the IDE complaining about errors that do not exist?). The IDE causes a segmentation fault if I use the Sun JDK 1.6.0_07 and I receive an UnspportedClassVersionError if I use version 1.5, so I am forced to use 1.6.0_10. The IDE is barely responsive on a 3.2GHz machine with 1.5GB memory and it doesn’t even align scaladoc comments properly as you write them. I am constantly manually fixing up indentation in the source code.
With so many elementary failures, I think any reasonable person would concede that IntelliJ IDEA is as unusable as Eclipse. That ends my whinge; thanks for listening.
http://realtimecollisiondetection.net/blog/?p=81
My favourites:
In contrast, design patterns are purported “master programmer advice” strongly suggesting to young or otherwise impressionable programmers that the design patterns convey important concepts, practices, or principles that have been “prethought.” However, design patterns are not “master programmer advice!”
Far from “master programmers,” design patterns are the work of people who do conferences, talks, and books for a living, to further their own cause
And the clincher:
Design patterns are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it.
I’m sure you knew you’d be standing on toes, despite the the overwhelmingly defensible truth value of your statements. Don’t adjust your sight Christer, it’s dead on target ;)
Below is a neat trick that others may find useful when designing APIs using the Scala programming language.
Scala’s type inferencer is not as clever as some. As a result, we often find ourselves explicitly annotating type variables in certain contexts. This can become a little annoying, but what is worse, is if you have a type variable list and only one of those requires explicit specification, the others must also be explicitly specified even though they would have otherwise been inferred.
Let me demonstrate. I will use Scala’s higher-kinds, which are never inferred (this is quite acceptable given the problems associated with inferring higher-kinds – consider Java and C# where they do not even exist, thus leading to an enormous repetitive chore) though other examples may be applicable. However, it can be annoying if you were to write say, the Monad join function:
def join[M[_], A](m: M[M[A]]): M[A] = error("todo")A caller invocation might look like:
val x = join[List, Int](List(List(1, 2, 3), List(4, 5, 6)))Notice the explicit annotation with the List type constructor, however, the second type variable (Int) must also be explicitly specified, even though it could have otherwise been inferred. This is a bit annoying.
We can do away with it like so:
def join[M[_]] = new {
def apply[A](m: M[M[A]]): M[A] = error("todo")
}And now the caller code no longer has that clumsy type annotation:
val x = join[List](List(List(1, 2, 3), List(4, 5, 6)))Yay! Have a nice day :)
class Fluffy f where
furry :: (a -> b) -> f a -> f b
-- Exercise 1
-- Relative Difficulty: 1
instance Fluffy [] where
furry = error "todo"
-- Exercise 2
-- Relative Difficulty: 1
instance Fluffy Maybe where
furry = error "todo"
-- Exercise 3
-- Relative Difficulty: 5
instance Fluffy ((->) t) where
furry = error "todo"
newtype EitherLeft b a = EitherLeft (Either a b)
newtype EitherRight a b = EitherRight (Either a b)
-- Exercise 4
-- Relative Difficulty: 5
instance Fluffy (EitherLeft t) where
furry = error "todo"
-- Exercise 5
-- Relative Difficulty: 5
instance Fluffy (EitherRight t) where
furry = error "todo"
class Misty m where
banana :: (a -> m b) -> m a -> m b
unicorn :: a -> m a
-- Exercise 6
-- Relative Difficulty: 3
-- (use banana and/or unicorn)
furry' :: (a -> b) -> m a -> m b
furry' = error "todo"
-- Exercise 7
-- Relative Difficulty: 2
instance Misty [] where
banana = error "todo"
unicorn = error "todo"
-- Exercise 8
-- Relative Difficulty: 2
instance Misty Maybe where
banana = error "todo"
unicorn = error "todo"
-- Exercise 9
-- Relative Difficulty: 6
instance Misty ((->) t) where
banana = error "todo"
unicorn = error "todo"
-- Exercise 10
-- Relative Difficulty: 6
instance Misty (EitherLeft t) where
banana = error "todo"
unicorn = error "todo"
-- Exercise 11
-- Relative Difficulty: 6
instance Misty (EitherRight t) where
banana = error "todo"
unicorn = error "todo"
-- Exercise 12
-- Relative Difficulty: 3
jellybean :: (Misty m) => m (m a) -> m a
jellybean = error "todo"
-- Exercise 13
-- Relative Difficulty: 6
apple :: (Misty m) => m a -> m (a -> b) -> m b
apple = error "todo"
-- Exercise 14
-- Relative Difficulty: 6
moppy :: (Misty m) => [a] -> (a -> m b) -> m [b]
moppy = error "todo"
-- Exercise 15
-- Relative Difficulty: 6
-- (bonus: use moppy)
sausage :: (Misty m) => [m a] -> m [a]
sausage = error "todo"
-- Exercise 16
-- Relative Difficulty: 6
-- (bonus: use apple + furry')
banana2 :: (Misty m) => (a -> b -> c) -> m a -> m b -> m c
banana2 = error "todo"
-- Exercise 17
-- Relative Difficulty: 6
-- (bonus: use apple + banana2)
banana3 :: (Misty m) => (a -> b -> c -> d) -> m a -> m b -> m c -> m d
banana3 = error "todo"
-- Exercise 18
-- Relative Difficulty: 6
-- (bonus: use apple + banana3)
banana4 :: (Misty m) => (a -> b -> c -> d -> e) -> m a -> m b -> m c -> m d -> m e
banana4 = error "todo"
newtype State s a = State {
state :: (s -> (s, a))
}
-- Exercise 19
-- Relative Difficulty: 9
instance Fluffy (State s) where
furry = error "todo"
-- Exercise 20
-- Relative Difficulty: 10
instance Misty (State s) where
banana = error "todo"
unicorn = error "todo"From “Never again will I doom the earth because of man…” By: God By J.D. Longstreet.
The argument goes something like this. Man cannot destroy the world, since Genesis 8:21 says so. Therefore, Global Warming is a conspiracy by scientific illiterates. Yes I cringed in embarrassment too.
Ignoring the scary implications of the prevalence of this kind of superstitious crackpottery, consider the somewhat amusing (I thought so anyway) excerpt below:
Then they [the Global Warming conspirators] use the guilt trip they have imposed on fellow human beings to shame us into completely altering the way we live. It is the oldest con game in the book. And the peoples of the planet are falling for it.
I wonder which book that might be :)
I will be publishing answers to these exercises as well as the Revised Scala Exercises in the near future. In the meantime, see if you can tackle the exercises below. In almost all cases, the type signature is enough to derive what the implementation should be. In all other cases, the solution is as difficult to derive anyway, so consider it an equivalent achievement.
The source file below compiles, but is missing certain function implementations (where you see error("todo")). Enjoy and if you have questions, please feel free to post them :)
trait PartialType[T[_, _], A] {
type Apply[B] = T[A, B]
type Flip[B] = T[B, A]
}
trait Fluffy[F[_]] {
def furry[A, B](f: A => B, fa: F[A]): F[B]
}
object Fluffy {
// Exercise 1
// Relative Difficulty: 1
def ListFluffy: Fluffy[List] = error("todo")
// Exercise 2
// Relative Difficulty: 1
def OptionFluffy: Fluffy[Option] = error("todo")
// Exercise 3
// Relative Difficulty: 1
def StreamFluffy: Fluffy[Stream] = error("todo")
// Exercise 4
// Relative Difficulty: 1
def ArrayFluffy: Fluffy[Array] = error("todo")
// Exercise 5
// Relative Difficulty: 5
def Function1Fluffy[X]: Fluffy[PartialType[Function1, X]#Apply] =
error("todo")
// Exercise 6
// Relative Difficulty: 6
def EitherLeftFluffy[X]: Fluffy[PartialType[Either.LeftProjection, X]#Flip] =
error("todo")
// Exercise 7
// Relative Difficulty: 4
def EitherRightFluffy[X]: Fluffy[PartialType[Either.RightProjection, X]#Apply] =
error("todo")
}
trait Misty[M[_]] extends Fluffy[M] {
def banana[A, B](f: A => M[B], ma: M[A]): M[B]
def unicorn[A](a: A): M[A]
// Exercise 8
// Relative Difficulty: 3
// (use banana and/or unicorn)
def furry[A, B](f: A => B, ma: M[A]): M[B] = error("todo")
}
object Misty {
// Exercise 9
// Relative Difficulty: 2
def ListMisty: Misty[List] = error("todo")
// Exercise 10
// Relative Difficulty: 2
def OptionMisty: Misty[Option] = error("todo")
// Exercise 11
// Relative Difficulty: 2
def StreamMisty: Misty[Stream] = error("todo")
// Exercise 12
// Relative Difficulty: 2
def ArrayMisty: Misty[Array] = error("todo")
// Exercise 13
// Relative Difficulty: 6
def Function1Misty[X]: Misty[PartialType[Function1, X]#Apply] =
error("todo")
// Exercise 14
// Relative Difficulty: 7
def EitherLeftMisty[X]: Misty[PartialType[Either.LeftProjection, X]#Flip] =
error("todo")
// Exercise 15
// Relative Difficulty: 5
def EitherRightMisty[X]: Misty[PartialType[Either.RightProjection, X]#Apply] =
error("todo")
// Exercise 16
// Relative Difficulty: 3
def jellybean[M[_], A](ma: M[M[A]], m: Misty[M]): M[A] = error("todo")
// Exercise 17
// Relative Difficulty: 6
def apple[M[_], A, B](ma: M[A], mf: M[A => B], m: Misty[M]): M[B] =
error("todo")
// Exercise 18
// Relative Difficulty: 6
def moppy[M[_], A, B](as: List[A], f: A => M[B], m: Misty[M]): M[List[B]] =
error("todo")
}
object AdvancedFun {
case class State[S, A](f: S => (S, A))
// Exercise 19
// Relative Difficulty: 9
def StateFluffy[S]: Fluffy[PartialType[State, S]#Apply] = error("todo")
// Exercise 20
// Relative Difficulty: 10
def StateMisty[S]: Misty[PartialType[State, S]#Apply] = error("todo")
}Prove ∀A. ∀B. ∀C. ((A∧B)→C)→A→B→C with a truth table.
WTF does that mean? It means that for any three propositions (A, B, C), then the conjunction (logical AND) of A and B implies C implies A implies B implies C. Note that → is right-associative, so X→Y→Z is the same as X→(Y→Z). If you are unfamiliar with denotational semantics (these crazy symbols), then perhaps this more relaxed notation makes sense forall A B C. ((A, B) -> C) -> A -> B -> C. Remember this notation, because we will use it later.
Here are some truth tables for conjunction and implication to get started:
Conjunction
P Q P∧Q
0 0 0
0 1 0
1 0 0
1 1 1
Implication
P Q P→Q
0 0 1
0 1 1
1 0 0
1 1 1We can prove the truth of the above statement by observing a tautology (all true values) in a truth table.
1 2 3 4 5 6 7 8
A B C A∧B (A∧B)→C B→C A→B→C ((A∧B)→C)→A→B→C
0 0 0 0 1 1 1 1
0 0 1 0 1 1 1 1
0 1 0 0 1 0 1 1
0 1 1 0 1 1 1 1
1 0 0 0 1 1 1 1
1 0 1 0 1 1 1 1
1 1 0 1 0 0 0 1
1 1 1 1 1 1 1 1Observe that column 8 is true. Therefore ∀A. ∀B. ∀C. ((A∧B)→C)→A→B→C is a true statement.
Remember this statement earlier forall A B C. ((A, B) -> C) -> A -> B -> C? If you have GHCiinstalled, go to the prompt and type :set -fglasgow-exts. Then ask for the type of the curry function :type curry. You will see this:
Prelude> :type curry
curry :: forall a b c. ((a, b) -> c) -> a -> b -> cSame same! :)
OK, so Haskell is for crazy people who use (oh dear!) logic which has nothing to do with that real world and they should all be writing enterprise Java applications like real programmers, right? Yeah right. Yep uh huh.
So let’s write this in Java, just for kicks and just to be noisy. Start with the conjunction and implication primitives:
interface Implication<P, Q> {
Q implies(P p);
}
interface Conjunction<P, Q> {
P p();
Q q();
}Next write the method for representing the aforementioned statement:
class S {
static <A, B, C> Implication<Implication<Conjunction<A, B>, C>, Implication<A, Implication<B, C>>> s() {
return null; // todo
}
}I shall leave it as a reader exercise to implement the s method. I assure you of only one possible implementation if you do not use null, exceptions or side-effects.
Function currying, like all programming concepts, is a logical statement under the Curry-Howard Isomorphism. Have a nice day :)
Once upon a time, I tried to write some Scala 2.7.1 for Functional Java and Reductio, but the compiler broke. So I filed the bug and waited for a fix. Thanks to Odersky et. al., the fix came promptly, so I started using one of the Scala 2.7.1->2.7.2 nightly builds and then I could compile my Scala code, yay! But that didn’t stop users complaining about crashes when using Scala 2.7.1 due its bad class file parser. Some users even stopped using Reductio because they don’t trust non-release builds. Oh well.
So I try out this new code snippet, nothing complicated:
class Foo[F[_]]
object Foo {
def foo(n: Int)(implicit f: Foo[IN] forSome { type IN[_] }) = "foo"
implicit val z: Foo[List] = new Foo[List]
val t = foo(7)
}But Scala 2.7.1 falls over. So does the 2.7.1->2.7.2 nightly build that I was using. Ugh! So I try out Scala 2.7.2-RC1, yay it compiles my legitimate source file. But does it compile all my other source?
Er no, Scala 2.7.2-RC1 produces bad class files when compiling code that is otherwise fine with previous Scala versions. In an attempt to obtain one bug fix I have also had to adopt another – one that makes its use non-viable. I am stuck with dealing with the former bug, which is also somewhat non-viable but only slightly more so than the latter. Give me a friggin’ break!
Ugh, this is not the first occurrence of this silliness. Flippin’ Scala, does this shit ever stop?
We use logic every day. No, I don’t mean just us programmers; I mean all of us. Here is an observation about propositional logic:
I have three propositions P, Q and R.
It doesn’t matter what these three propositions actually are, it will always hold that, “if P then Q implies that if Q then R implies that if P then R”.
I’ve subverted that a little to try to make it read a little better, but perhaps look it at it a bit more formally:
forall P Q R. (P → Q) → (Q → R) → (P → R)You might like to try it out on paper using some example propositions, such as:
P = Today is Tuesday
Q = I am going swimming
R = I have hairy armpits
I won’t bastardise it with English again ;) However, I will give you a hint. Here is the truth table for → (logical implication):
A | B | A → B
0 | 0 | 1
0 | 1 | 1
1 | 0 | 0
1 | 1 | 1Here is where it gets a little interesting. This same logical statement forall P Q R. (P → Q) → (Q → R) → (P → R) can also be expressed in most programming languages. Here it is in Java as the z method:
interface F<A, B> { B f(A a); }
static <P, Q, R> F<P, R> z(F<P, Q> f, F<Q, R> g) { ...It gets more interesting; there is only one implementation of this function if we assume a terminating subset of the language (for Java, no null or throwing an exception). If you add in a side-effect such as writing to a file or the network, then you have perverted the function signature. Java allows us to do that, so we also have to assume a subset of the language that disallows this unfortunate anomaly. This notion of a type signature having only one implementation is called once inhabited.
Let’s write out the truth table for this. Notice the consistent 1 values in the final column. The statement is a tautology.
P | Q | R | P → R | Q → R | P → R | (Q → R) → P → R | (P → Q) → (Q → R) → P → R
0 | 0 | 0 | 1 | 1 | 1 | 1 | 1
0 | 0 | 1 | 1 | 1 | 1 | 1 | 1
0 | 1 | 0 | 1 | 0 | 1 | 1 | 1
0 | 1 | 1 | 1 | 1 | 1 | 1 | 1
1 | 0 | 0 | 0 | 1 | 0 | 0 | 1
1 | 0 | 1 | 0 | 1 | 1 | 1 | 1
1 | 1 | 0 | 1 | 0 | 0 | 1 | 1
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1Under the Curry-Howard Isomorphism, logical implication is represented by a function or in the example above using Java, by the F interface. The z function is called function composition. It takes the two give functions/propositions and composes them.
In Haskell, function composition is not called z as we called it with Java, but instead (.). That’s a full-stop character in parentheses. We can ask for the type of (.) in the GHC interpreter:
Prelude> :type (.)
(.) :: (b -> c) -> (a -> b) -> a -> cWe might even call it by passing in function instances (similar to instances of the Java F interface):
Prelude> ((+1) . (*7)) 20
141
Prelude> (reverse . map Char.toUpper) "hello there"
"EREHT OLLEH"You could do the same using Java, but it’s a little more verbose, so I’ll omit that ;)
Here is a simple quiz. If we suppose the same F interface earlier, how many implementations of this function are there:
static <a> F<A, A> t() { ...What about this one?
static <A, B> F<A, B> u() { ...There are a few possibilities for improvement on this Scala Swing Example.
Removed unnecessary semi-colons
Inlined import
Removed = in main declaration (strongly advised on functions returning Unit and especially more for main)
Removed a few unnecessary parentheses
import javax.swing._
import java.awt.event.{ActionEvent, ActionListener}
object HelloWorld extends JFrame("Hello Swing") {
def showButtonMessage(msg: String) =
JOptionPane.showMessageDialog(null, String.format("""<html>Hello from <b>Scala</b>. Button %s pressed""", Array(msg)));
def main(args: Array[String]) {
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
val button = new JButton("Click Me")
button.addActionListener((e:ActionEvent) => showButtonMessage(e.getActionCommand.toString))
getContentPane add button
pack
setVisible(true)
}
implicit def actionPerformedWrapper(func: (ActionEvent) => Unit) = new ActionListener {
def actionPerformed(e:ActionEvent) = func(e)
}
}Patient: I have 6 potentially failing methods (a, b, c, d, e, f) and if one of those fails, I want to cease execution and return that failure, otherwise continue execution.
Doctor: What do they return if they succeed?
Patient: Nothing, they side-effect
Doctor: eek! OK, let’s see what we can do? What happens after you’ve completed this computation?
Patient: Well, it gets a bit hairier you see. Then I have 3 more potentially failing computations (g, h, i) and if any of those fail (or the original failed), then I also want to fail, however, I want to keep the errors in these last three computations.
Doctor: So let’s get this right, you perform all of the latter three computations regardless of their outcome and you only succeed if all nine computations succeed and you fail otherwise?
Patient: Yes, that’s right and…
Doctor: And for whatever silly reason, you’re using Java.
Patient: cowers; er yeah.
Doctor: Well, I’ve told you about that, haven’t I?
Patient: cowers more; yes you have but…
Doctor: So, if any of the first six computations fail, then you check the latter three for failures as well. These latter three are side-effecting, void return type, as well aren’t they?
Patient: Yes…
Doctor: If the first six succeed, you perform the latter three computations anyway, accumulating potential failures.
Patient: Right, exactly
Doctor: And just as an interesting observation, you will have at most, four errors and possibly none in the event of all nine succeeding.
Patient: Umm yeah, I hadn’t thought of it that way.
Doctor: smiles
Validation<Throwable, Unit> a;
Validation<Throwable, Unit> b;
Validation<Throwable, Unit> c;
Validation<Throwable, Unit> d;
Validation<Throwable, Unit> e;
Validation<Throwable, Unit> f;
////
Validation<Throwable, Unit> g;
Validation<Throwable, Unit> h;
Validation<Throwable, Unit> i;
Validation<Throwable, Unit> first() {
return a.sequence(b).
sequence(c).
sequence(d).
sequence(e).
sequence(f);
}
Option<NonEmptyList<throwable>> second() {
return first().nel().accumulate(Semigroup.<throwable>nonEmptyListSemigroup(),
g.nel(),
h.nel(),
i.nel());
}Doctor: Now, this is the best that Java can do at solving this very popular request of yours, but come and see me when you’re ready to upgrade your tools…
Patient: Thanks Doc! I will!
Doctor: outward smile, inward scepticism; In the meantime, I will prescribe you with Functional Java 2.9 which is only going to work if you exercise at least some amount of intellectual discipline. You will need it for the solution above.
Doctor: On your way then.
Update: Functional Java 2.10 includes Validation.sequence.
Right ankle sprain
Fifth life-time occurrence
X-Ray reveals no fracture (Royal Brisbane Hospital)
Zero weight bearing for 6 days
Certain movements cause swelling and discomfort
Movement is restricted in bending the knee with the foot flat on the ground (name?) – can get the knee vertical with the tip of the foot, but no further
MRI ordered by local GP (see below)
Radiography report is unremarkable and states no anterolateral abnormality (even though the pain is posteromedial?)
Local GP administers cortico-steroid injection. Due to the swelling, the exact site of the pain cannot be accurately located. Since swelling has stopped (I have ceased rigorous activity), I estimate that the injection missed by about 2cm.
Improvement over the following 3 weeks and flexibility increases, just a little (I can get my knee 3cm passed the tip of my foot vertically)
Ceased all sporting activity, in particular squash (3 times per week, including A1 grade competition)
This was due to this injury and one other; scapholunate ligament tear resulting in instability
Subcutaneous atrophy from steroid injection begins to subside
Further injections are advised against by local GP
Arthroscopy of the wrist for scapholunate ligament repair (Dr. Peter Rowan, BOSMC)
Wrist Arthroscopy has failed (reconstruction pending?)
HELP!
Appointment with Greg Sterling on 30 September
YAY! 57 sleeps to go
Taken 2 August 2008
Red mark denotes site of impingement
Note atrophy below the mark
Radiographer Report (Transcribed)
All DICOM images (tar.gz) 71MB
MR000000 MR000000 MR000000 MR000000 MR000000 MR000001 MR000001 MR000001 MR000001 MR000001 MR000002 MR000002 MR000002 MR000002 MR000002 MR000003 MR000003 MR000003 MR000003 MR000003 MR000004 MR000004 MR000004 MR000004 MR000004 MR000005 MR000005 MR000005 MR000005 MR000005 MR000006 MR000006 MR000006 MR000006 MR000006 MR000007 MR000007 MR000007 MR000007 MR000007 MR000008 MR000008 MR000008 MR000008 MR000008 MR000009 MR000009 MR000009 MR000009 MR000009 MR000010 MR000010 MR000010 MR000010 MR000010 MR000011 MR000011 MR000011 MR000011 MR000011 MR000012 MR000012 MR000012 MR000012 MR000012 MR000013 MR000013 MR000013 MR000013 MR000013 MR000014 MR000014 MR000014 MR000014 MR000014 MR000015 MR000015 MR000015 MR000015 MR000015 MR000016 MR000016 MR000016 MR000016 MR000016 MR000017 MR000017 MR000017 MR000017 MR000017 MR000018 MR000018 MR000018 MR000018 MR000018 MR000019 MR000019 MR000019 MR000019 MR000019 MR000020 MR000020 MR000020 MR000020 MR000020 MR000021 MR000021 MR000021 MR000021 MR000021 MR000022 MR000022 MR000022 MR000022 MR000022 MR000023 MR000023 MR000023 MR000023 MR000023
All PNG images (tar.gz) 23MB
MR000000 MR000000 MR000000 MR000000 MR000000 MR000001 MR000001 MR000001 MR000001 MR000001 MR000002 MR000002 MR000002 MR000002 MR000002 MR000003 MR000003 MR000003 MR000003 MR000003 MR000004 MR000004 MR000004 MR000004 MR000004 MR000005 MR000005 MR000005 MR000005 MR000005 MR000006 MR000006 MR000006 MR000006 MR000006 MR000007 MR000007 MR000007 MR000007 MR000007 MR000008 MR000008 MR000008 MR000008 MR000008 MR000009 MR000009 MR000009 MR000009 MR000009 MR000010 MR000010 MR000010 MR000010 MR000010 MR000011 MR000011 MR000011 MR000011 MR000011 MR000012 MR000012 MR000012 MR000012 MR000012 MR000013 MR000013 MR000013 MR000013 MR000013 MR000014 MR000014 MR000014 MR000014 MR000014 MR000015 MR000015 MR000015 MR000015 MR000015 MR000016 MR000016 MR000016 MR000016 MR000016 MR000017 MR000017 MR000017 MR000017 MR000017 MR000018 MR000018 MR000018 MR000018 MR000018 MR000019 MR000019 MR000019 MR000019 MR000019 MR000020 MR000020 MR000020 MR000020 MR000020 MR000021 MR000021 MR000021 MR000021 MR000021 MR000022 MR000022 MR000022 MR000022 MR000022 MR000023 MR000023 MR000023 MR000023 MR000023
It is better not to believe in God, since if he does not exist, you lose nothing, but if he does exist, you are going to hell, where it is nice and warm. Winter sucks.
Without the rules as per last time, I have rewritten the Scala exercises to be closer to the Haskell revision. Enjoy :)
(And yes, I will get around to giving you all feedback (you should also see my email inbox) – just hang in there!).
sealed trait List[+A] {
override def toString = {
def toScalaList(t: List[A]): scala.List[A] = t match {
case Empty => Nil
case Cons(h, t) => h :: toScalaList(t)
}
toScalaList(this).toString
}
}
final case object Empty extends List[Nothing]
final case class Cons[A](h: A, t: List[A]) extends List[A]
object List {
def foldRight[A, B](as: List[A], b: B, f: (A, B) => B): B = as match {
case Empty => b
case Cons(h, t) => f(h, foldRight(t, b, f))
}
def foldLeft[A, B](as: List[A], b: B, f: (B, A) => B): B = as match {
case Empty => b
case Cons(h, t) => foldLeft(t, f(b, h), f)
}
def reduceRight[A](as: List[A], f: (A, A) => A): A = as match {
case Empty => error("bzzt. reduceRight on empty list")
case Cons(h, t) => foldRight(t, h, f)
}
def reduceLeft[A](as: List[A], f: (A, A) => A): A = as match {
case Empty => error("bzzt. reduceLeft on empty list")
case Cons(h, t) => foldLeft(t, h, f)
}
def unfold[A, B](b: B, f: B => Option[(A, B)]): List[A] = f(b) match {
case Some((a, b)) => Cons(a, unfold(b, f))
case scala.None => Empty
}
}
sealed trait Natural {
override def toString = {
def toInt(n: Natural): Int = n match {
case Zero => 0
case Succ(x) => 1 + toInt(x)
}
toInt(this).toString
}
}
final case object Zero extends Natural
final case class Succ(c: Natural) extends Natural
object Exercises {
// Exercise 1
// Relative Difficulty: 1
// Correctness: 2.0 marks
// Performance: 0.5 mark
// Elegance: 0.5 marks
// Total: 3
def add(x: Natural, y: Natural): Natural = error("todo")
// Exercise 2
// Relative Difficulty: 2
// Correctness: 2.5 marks
// Performance: 1 mark
// Elegance: 0.5 marks
// Total: 4
def sum(is: List[Int]): Int = error("todo")
// Exercise 3
// Relative Difficulty: 2
// Correctness: 2.5 marks
// Performance: 1 mark
// Elegance: 0.5 marks
// Total: 4
def length[A](as: List[A]): Int = error("todo")
// Exercise 4
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.0 mark
// Elegance: 1.5 marks
// Total: 7
def map[A, B](as: List[A], f: A => B): List[B] = error("todo")
// Exercise 5
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def filter[A](as: List[A], f: A => Boolean): List[A] = error("todo")
// Exercise 6
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def append[A](x: List[A], y: List[A]): List[A] = error("todo")
// Exercise 7
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def flatten[A](as: List[List[A]]): List[A] = error("todo")
// Exercise 8
// Relative Difficulty: 7
// Correctness: 5.0 marks
// Performance: 1.5 marks
// Elegance: 1.5 mark
// Total: 8
def flatMap[A, B](as: List[A], f: A => List[B]): List[B] = error("todo")
// Exercise 9
// Relative Difficulty: 8
// Correctness: 3.5 marks
// Performance: 3.0 marks
// Elegance: 2.5 marks
// Total: 9
def maximum(is: List[Int]): Int = error("todo")
// Exercise 10
// Relative Difficulty: 10
// Correctness: 5.0 marks
// Performance: 2.5 marks
// Elegance: 2.5 marks
// Total: 10
def reverse[A](as: List[A]): List[A] = error("todo")
}Functional Java 2.8 contains a concurrency API that implements Actors as seen in Erlang and Scala. This allows a user to take advantage of multiple core machines in their Java code.
Runar has written articles explain how to use the API – it’s pretty darn easy for a client – just don’t look under the hood ;)
Higher-Order Java Parallelism, Part 1: Parallel Strategies and the Callable Monad
Higher-Order Java Parallelism, Part 2: Parallel List Transformations
Here is an example of a parallel fibonacci that uses a few hundred virtual threads (unlike the ping/pong example that uses… wait for it… millions of virtual threads!). On my quad-core machine, the fibonacci computation speeds up by about 6 times (45 seconds serially to about 7 seconds when using actors).
The example uses Java 7 BGGA syntax (imports omitted) and after compilation, runs fine on any 1.5 JVM. This example is also available with Java 1.5 source code in the Functional Java release.
/**
* Parallel Fibonacci numbers.
* Based on a Haskell example by Don Stewart.
* Author: Runar
*/
public class Fibs {
private static final int CUTOFF = 35;
public static void main(final String[] args) throws Exception {
if (args.length < 1)
throw error("This program takes an argument: number_of_threads");
final int threads = Integer.parseInt(args[0]);
final ExecutorService pool = Executors.newFixedThreadPool(threads);
final Strategy<unit> su = Strategy.executorStrategy(pool);
final Strategy<Promise<integer>> spi = Strategy.executorStrategy(pool);
final Actor<List<integer>> out = actor(su, { List<integer> fs => {
int i = 0;
for (List<integer> ns = fs; ns.isNotEmpty(); ns = ns.tail()) {
System.out.println(MessageFormat.format("n={0}=>{1}", i, ns.head()));
i++;
}
pool.shutdown();
}});
System.out.println("Calculating Fibonacci sequence in parallel...");
final F<Integer, Promise<integer>> fib = { Integer n => (n < CUTOFF) ?
promise(su, P.p(serialFib(n))) :
fib.f(n - 1).bind(join(su, P1.curry(fib).f(n - 2)), { int a => { int b => a + b }} ) };
join(su, fmap(Promise.<integer>sequence(su)).f(spi.parMap(fib).f(range(0, 46)))).to(out);
}
public static int serialFib(final int n) {
if (n < 2)
return n;
else return serialFib(n - 1) + serialFib(n - 2);
}
}The exercises below are similar to my previous ‘Scala exercises for beginners’, except the rules a little clearer. For those of who have emailed me or submitted responses here on the blog, I will get around to providing you feedback, however, I’d prefer to do so on the revised version of the Exercises since then I can maintain a bit of clarity in explaining the solutions; specifically, why one may be preferred over another. I hope you don’t mind.
If you have not used Haskell before, download and install GHC, start up the interpreter (ghci) and load the source file. e.g. :load Exercises.hs If you are on Debian, you can install GHC and start the interpreter with: apt-get install ghc6 && ghci.
The source file below can be found here.
-- + Complete the 10 exercises below by filling out the function bodies.
-- The code currently compiles, but none of the tests pass (the test function).
-- Replace the function bodies (error "todo") with an appropriate solution.
-- + These exercises may be done in any order, however:
-- Exercises are generally increasing in difficulty, though some people may find later exercise easier.
-- The tests are written to execute in the order 1 to 10, so you need to have Exercise n passing before Exercise (n+1) passes.
-- + Note the existence of the library function max :: Int -> Int -> Int which will help you with Exercise 9.
-- + Bonus for using the provided functions or for using one exercise solution to help solve another.
-- + Approach with your best available intuition; just dive in and do what you can!
-- TOTAL marks: /66
module L02.List where
import Prelude hiding (sum, length, map, filter, maximum, reverse)
-- BEGIN Helper functions and data types
-- The custom list type
data List t = Nil | t :| List t deriving Eq
-- Right-associative
infixr 5 :|
instance (Show t) => Show (List t) where
show = show . foldRight (:) []
-- functions over List that you may consider using
foldRight :: (a -> b -> b) -> b -> List a -> b
foldRight _ b Nil = b
foldRight f b (h :| t) = f h (foldRight f b t)
foldLeft :: (b -> a -> b) -> b -> List a -> b
foldLeft _ b Nil = b
foldLeft f b (h :| t) = let b' = f b h in b' `seq` foldLeft f b' t
reduceRight :: (a -> a -> a) -> List a -> a
reduceRight _ Nil = error "bzzt. reduceRight on empty list"
reduceRight f (h :| t) = foldRight f h t
reduceLeft :: (a -> a -> a) -> List a -> a
reduceLeft _ Nil = error "bzzt. reduceLeft on empty list"
reduceLeft f (h :| t) = foldLeft f h t
-- END Helper functions and data types
-- BEGIN Exercises
-- Exercise 1
-- Relative Difficulty: 1
-- Correctness: 2.0 marks
-- Performance: 0.5 mark
-- Elegance: 0.5 marks
-- Total: 3
headOr :: List a -> a -> a
headOr = error "todo"
-- Exercise 2
-- Relative Difficulty: 2
-- Correctness: 2.5 marks
-- Performance: 1 mark
-- Elegance: 0.5 marks
-- Total: 4
sum :: List Int -> Int
sum = error "todo"
-- Exercise 3
-- Relative Difficulty: 2
-- Correctness: 2.5 marks
-- Performance: 1 mark
-- Elegance: 0.5 marks
-- Total: 4
length :: List a -> Int
length = error "todo"
-- Exercise 4
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.0 mark
-- Elegance: 1.5 marks
-- Total: 7
map :: (a -> b) -> List a -> List b
map = error "todo"
-- Exercise 5
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
filter :: (a -> Bool) -> List a -> List a
filter = error "todo"
-- Exercise 6
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
append :: List a -> List a -> List a
append = error "todo"
-- Exercise 7
-- Relative Difficulty: 5
-- Correctness: 4.5 marks
-- Performance: 1.5 marks
-- Elegance: 1 mark
-- Total: 7
flatten :: List (List a) -> List a
flatten = error "todo"
-- Exercise 8
-- Relative Difficulty: 7
-- Correctness: 5.0 marks
-- Performance: 1.5 marks
-- Elegance: 1.5 mark
-- Total: 8
flatMap :: (a -> List b) -> List a -> List b
flatMap = error "todo"
-- Exercise 9
-- Relative Difficulty: 8
-- Correctness: 3.5 marks
-- Performance: 3.0 marks
-- Elegance: 2.5 marks
-- Total: 9
maximum :: List Int -> Int
maximum = error "todo"
-- Exercise 10
-- Relative Difficulty: 10
-- Correctness: 5.0 marks
-- Performance: 2.5 marks
-- Elegance: 2.5 marks
-- Total: 10
reverse :: List a -> List a
reverse = error "todo"
-- END Exercises
-- BEGIN Tests for Exercises
test :: IO ()
test =
let showNil = show (Nil :: List Int)
results =
[
-- headOr
("headOr",
show (headOr (1 :| 2 :| 3 :| Nil) 7)
, show 1),
("headOr",
show (headOr Nil 8)
, show 8),
-- sum
("sum",
show (sum (1 :| 2 :| 3 :| Nil))
, show 6),
("sum",
show (sum Nil)
, show 0),
-- length
("length",
show (length ('a' :| 'b' :| 'c' :| Nil))
, show 3),
("length",
show (length Nil)
, show 0),
-- map
("map",
show (map (+1) (1 :| 2 :| 3 :| Nil))
, show (2 :| 3 :| 4 :| Nil)),
("map",
show (map (+1) Nil)
, showNil),
-- filter
("filter",
show (filter even (1 :| 2 :| 3 :| Nil))
, show (2 :| Nil)),
("filter",
show (filter even Nil)
, showNil),
-- append
("append",
show (append (1 :| 2 :| 3 :| Nil) (4 :| Nil))
, show (1 :| 2 :| 3 :| 4 :| Nil)),
("append",
show (append (1 :| 2 :| 3 :| Nil) Nil)
, show (1 :| 2 :| 3 :| Nil)),
-- flatten
("flatten",
show (flatten ((1 :| 2 :| Nil) :| ((3 :| 4 :| Nil) :| Nil)))
, show (1 :| 2 :| 3 :| 4 :| Nil)),
-- flatMap
("flatMap",
show (flatMap (\n -> (n+1) :| (n+2) :| Nil) (1 :| 2 :| 3 :| Nil))
, show (2 :| 3 :| 3 :| 4 :| 4 :| 5 :| Nil)),
-- maximum
("maximum",
show (maximum (3 :| 1 :| 2 :| Nil))
, show 3),
-- reverse
("reverse",
show (reverse (1 :| 2 :| 3 :| Nil))
, show (3 :| 2 :| 1 :| Nil))
]
check (n, a, b) = do print ("=== " ++ n ++ " ===")
print (if a == b then "PASS" else "FAIL Expected: " ++ b ++ " Actual: " ++ a)
in mapM_ check results
-- END Tests for Exercises
-- Utility
all ::
(a -> Bool)
-> List a
-> Bool
all p =
foldRight (&&) True . map p
isEmpty ::
List a
-> Bool
isEmpty Nil = True
isEmpty (_:|_) = False
contains ::
Eq a =>
List a
-> a
-> Bool
contains Nil _ = False
contains (h:|t) e = h == e || contains t eThe following exercises have come from of a course that I give on Functional Programming. I have assigned them difficulty ratings to make it a bit more exciting. Download the compilable source code from here or find it below. Enjoy :)
These exercises can be translated into any language powerful enough to possess algebraic data types and case matching (yes, I am talking to you). Haskell is another such language and I will convert these exercises to Haskell if prompted.
// You are not permitted to use these List methods:
// * length
// * map
// * filter
// * ::: (and variations such as ++)
// * flatten
// * flatMap
// * reverse (and variations i.e. reverseMap, reverse_:::)
// This also means you are not permitted to use for-comprehensions on Lists.
// You are permitted to use the functions you write yourself. For example, Exercise 2 may use Exercise 1 or Exercise 3.
// Using permitted existing methods where appropriate will attract marks for elegance.
// TOTAL marks: /66
object Exercises {
def succ(n: Int) = n + 1
def pred(n: Int) = n - 1
// Exercise 1
// Relative Difficulty: 1
// Correctness: 2.0 marks
// Performance: 0.5 mark
// Elegance: 0.5 marks
// Total: 3
def add(x: Int, y: Int): Int = error("todo: Assume x and y are 0 or positive. Do not use + or - on Int. Only permitted to use succ/pred (above).")
// Exercise 2
// Relative Difficulty: 2
// Correctness: 2.5 marks
// Performance: 1 mark
// Elegance: 0.5 marks
// Total: 4
def sum(x: List[Int]): Int = error("todo")
// Exercise 3
// Relative Difficulty: 2
// Correctness: 2.5 marks
// Performance: 1 mark
// Elegance: 0.5 marks
// Total: 4
def length[A](x: List[A]): Int = error("todo")
// Exercise 4
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.0 mark
// Elegance: 1.5 marks
// Total: 7
def map[A, B](x: List[A], f: A => B): List[B] = error("todo")
// Exercise 5
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def filter[A](x: List[A], f: A => Boolean): List[A] = error("todo")
// Exercise 6
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def append[A](x: List[A], y: List[A]): List[A] = error("todo")
// Exercise 7
// Relative Difficulty: 5
// Correctness: 4.5 marks
// Performance: 1.5 marks
// Elegance: 1 mark
// Total: 7
def concat[A](x: List[List[A]]): List[A] = error("todo")
// Exercise 8
// Relative Difficulty: 7
// Correctness: 5.0 marks
// Performance: 1.5 marks
// Elegance: 1.5 mark
// Total: 8
def concatMap[A, B](x: List[A], f: A => List[B]): List[B] = error("todo")
// Exercise 9
// Relative Difficulty: 8
// Correctness: 3.5 marks
// Performance: 3.0 marks
// Elegance: 2.5 marks
// Total: 9
def maximum(x: List[Int]): Int = error("todo")
// Exercise 10
// Relative Difficulty: 10
// Correctness: 5.0 marks
// Performance: 2.5 marks
// Elegance: 2.5 marks
// Total: 10
def reverse[A](x: List[A]): List[A] = error("todo")
}When some programmers pick up a functional programming language like Microsoft Excel, they stop caring about identifier names.
A1 = blah
B1 = function(A1, C2)
...Can this observation be explained while maintaining consistency? I think it can.
Some programmers are married to the imperative, side-effecting mindset. This makes them fearful of Scala’s implicit keyword (among many other high-level programming constructs and abstractions). You can read all sorts of amateurish criticism of this language construct on various websites, but I plan to show why they are a necessity to the language being useful (in the intellectually true and meaningful sense – not in a “Java” “pragmatist” sense (I know I’m treading on thin ice here, but the point is worthwhile)).
I also do not plan to address the amateurish claims specifically, since if you are like me, you simply acknowledge their existence, feel a bit sad, then get over it and move on. I mention these cases so that they can be contrasted to my plan to address a discussion I had with someone (who shall remain nameless for now and leave it up to them if they wish to reveal themselves) who put forward an intellectually constructed argument about why they can/should be eliminated. These kind of discussions are very purposeful. While my opponent’s argument was well thought-out (in contrast to the aforementioned), I still think it is wrong. Here is why.
You can do away with implicit definitions in favour of named functions with partial application. This is true, but is it useful? Furthermore, Scala is not exactly friendly to partially applying function arguments, requiring varying levels of awkwardness in certain contexts. I will assume, since I am a nice guy, that this is not the case. I will now alter the argument to what I consider to be equivalent, “Haskell can do away with type-classes”. I altered the argument simply for the sake of brevity in discussion – I will tie it back to Scala code examples at the end.
Let us assume we get rid of just one Haskell type-class, Monad. A monad is a useful abstraction, so we would certainly have to represent it (if you don’t believe this, then it is almost certain that you have reinvented monads inadvertently). We might do this as follows:
{-# LANGUAGE RankNTypes #-}
data Monad' m = Monad' {
unit :: (forall a. a -> m a),
bind :: (forall a b. m a -> (a -> m b) -> m b)
}Then, when it comes to instances, we would write:
listMonad = Monad' (return :: a -> [a]) (>>=)
maybeMonad = Monad' (return :: a -> Maybe a) (>>=)Now when we wish to write the all-important functions over monads, we have to do the following:
sequence' monad [] = unit monad []
sequence' monad (x:xs) = let (>>>=) = bind monad in x >>>= \y -> sequence' monad xs >>>= \ys -> unit monad (y:ys)
mapM' monad f as = ... etc. etc.The proposal by my opponent in the discussion is that we now write a version of each monad function for each instance by partially applying the monad instance. This is very cumbersome and importantly, less useful.
~{.Haskell} listSequence = sequence’ listMonad maybeSequence = sequence’ maybeMonad
listMapM = mapM’ listMonad ~ … and so on.
This creates what would otherwise be code in the order of O(1) to turn into O(n) code! This is not good. Do we get any benefit? No, there is no benefit, other than, in the case of Scala, appeasement of ‘the irrational squad’ i.e. those fervently offended by the suggestion to divorce imperative programming. Let us just address this irrationality, even if just briefly, so we can move on.
Unlike Scala, Haskell’s side-effects are controlled, so the mind-shift is forced by the compiler (a successful form of counselling?). A Scala implicit function can perform side-effects. This would be very bad; if they were controlled, would these irrational objections be raised? The answer is no and it is quite easy to expose.
A claim to the contrary is often a case of doublethink. Java is a programming language that deliberately encourages side-effects and by implication (also, by its poor type system), makes abstraction and composition extremely difficult to the point of impossibility very early on (see Functional Java for evidence). Yet even in this language – perhaps the most contrived available – we find implicit conversions that attract no objections whatsoever!
Imagine this Java signature int toInt(char c). Such a user-defined function could indeed perform side-effects and any language feature permitting implicit use of this function is likely to attract criticism. Yet, this is one example of such a function built right-in to the Java language, which is guaranteed by the language specification to perform no side-effects. It is the fact that it is internalised by the user to perform no side-effects that makes it acceptable.
This is valid Java:
int i = c; // where c is of type charI don’t wish to labour this point, other than to make it clear how easy it is to crush these irrationalities (it continues on in a usual uninteresting fashion).
Requiring code to blow out to O(n) from O(1) is itself not bad, but to further observe that there is no gain from it is conclusive. Interestingly, this is similar to a complaint by David MacIver (and myself – I am just less vocal about it) that Scala lacks default function argument lists in preference for overloading. This also creates unnecessary code-bloat (O(1) -> O(n)) for no benefit. (I hope I am not misrepresenting David here – I have lost the reference to his complaint).
Here is the equivalent Scala code to the above, however, Scala’s type system lacks the ability to pass the unit and bind functions – instead requiring the use of traits.
trait Unit[U[_]] {
def unit[A](a: A): U[A]
}
trait Bind[M[_]] {
def bind[A, B](ma: M[A], f: A => M[B]): M[B]
}
case class Monad[M[_]](u: Unit[M], b: Bind[M])
object Monad {
val listMonad = Monad[List](new Unit[List] {
def unit[A](a: A) = List(a) }, new Bind[List] {
def bind[A, B](ma: List[A], f: A => List[B]) = ma flatMap f
})
def sequence[M[_], A](m: Monad[M], as: List[M[A]]): M[List[A]] = as match {
case Nil => m.u.unit(Nil)
case x :: xs => m.b.bind(x, (y: A) => m.b.bind(sequence[M, A](m, xs), (ys: List[A]) => m.u.unit(y::ys)))
}
def listSequence[A](as: List[List[A]]) = sequence[List, A](listMonad, as)
def optionSequence[A](as: List[List[A]]) = sequence[Option, A](optionMonad, as)
// etc. etc. O(n)!
}As you can see, I was being very nice when I converted the argument to Haskell. The argument against such a proposal becomes even stronger in the context of Scala.
To my opponent, thanks for the discussion; it was fun and the intellectual maturity is admirable :)
Here is the Applicative functor type-class (see Applicative Programming with Effects, Conor McBride, Ross Paterson):
class Applicative f where
pure :: a -> f a
(<*>) :: f (a -> b) -> f a -> f bHere are the laws for the Applicative functor type-class:
identitypure id <*> u == u
compositionpure (.) <*> u <*> v <*> w == u <*> (v <*> w)
homomorphismpure f <*> pure x == pure (f x)
interchangeu <*> pure x == pure (\f -> f x) <*> u
Here are those laws stated using Reductio. I have changed pure to unit and the language is Scala:
object ApplicativeLaws {
def identity[A[_], X](implicit a: Applicative[A],
aax: Arbitrary[A[X]],
e: Equal[A[X]]) =
prop((apx: A[X]) => apx === a(a.unit((x: X) => x), apx))
def composition[A[_], X, Y, Z](implicit a: Applicative[A],
aayz: Arbitrary[A[Y => Z]],
aaxy: Arbitrary[A[X => Y]],
aax: Arbitrary[A[X]],
e: Equal[A[Z]]) =
prop((apyz: A[Y => Z], apxy: A[X => Y], apx: A[X]) =>
a(apyz, a(apxy, apx)) ===
a(a(a(a.unit((f: Y => Z) => (g: X => Y) => f compose g), apyz), apxy), apx))
def homomorphism[A[_], X, Y](implicit a: Applicative[A],
ax: Arbitrary[X],
axy: Arbitrary[X => Y],
e: Equal[A[Y]]) =
prop((f: X => Y, x: X) => a(a.unit(f), a.unit(x)) === a.unit(f(x)))
def interchange[A[_], X, Y](implicit a: Applicative[A],
ax: Arbitrary[X],
apxy: Arbitrary[A[X => Y]],
e: Equal[A[Y]]) =
prop((f: A[X => Y], x: X) =>
a(f, a.unit(x)) === a(a.unit((f: X => Y) => f(x)), f))
}Pretty neat eh? :) Let’s test the Applicative instance for List:
List(identity[List, Int],
composition[List, Int, Long, String],
homomorphism[List, Int, String],
interchange[List, Int, String]).
foreach(p => summary println p)This runs 100 unit tests per property, so 400 unit tests altogether. Here is the output:
OK, passed 100 tests.
OK, passed 100 tests.
OK, passed 100 tests.
OK, passed 100 tests.Woot woot!
Runar recently made mention of these so-called Functors and Monads in his excellent post about concurrency/actors in Java. There are all sorts of tutorials out there for understanding what a Monad is, however, I am of the opinion that one must first understand what a Functor is. This is because it is less complex and more general (all monads are functors plus more).
The Java Posse also made a couple of false claims about Runar’s article, but one in particular needs addressing. This is the notion that a functor is applicable to “Functional Programming”. This is false. A functor is applicable to programming. You really, really need to understand what a functor is, if you’re ever going to be skilled in any type of programming; even if it’s just Java web applications for the rest of your life. This concept does not exist ‘on the other side of the fence’ in the imaginary ‘functional programming world’. These suggestions are understandable of course and I don’t intend to labour the point – only make this point clear, since these apparent divides seem to pop up often. On with the story…
In Java, we have an interface called [CharSequence](http://java.sun.com/javase/6/docs/api/java/lang/CharSequence.html). A few things can be said about CharSequence. How about:
All implementations guarantee that for some integer
n, then ifn >= 0 && n < length(), thencharAt(n)will not throw an exception.
We might call this a law about CharSequence that all implementations must satisfy. We could even find other laws that must satisfy about implementations of the CharSequence interface.
A Functor is an interface and it has two laws. Sadly though, this interface cannot be expressed using Java’s type system – it is simply not clever enough. We must use a hypothetical Java to express it. First though, we have to make up for Java’s missing first-class functions by using an interface. This is easy:
interface Function<A, B> {
B f(A a);
}OK, so this a just an interface like any others. It needn’t satisfy any laws; it just takes an argument (A) and returns (B). We could write bazillions of implementations of this interface in Java. We’re going to need this interface to write the Functor interface.
Now, the missing part of Java is called higher-kinds – a term you needn’t concern yourself with too much. I hope this hypothetical syntax is enough to make the point clear:
interface Functor<E<_>> {
<A, B> E<b> fmap(Function<A, B> f, E<a> fa);
}So the foreign part here is E<_>. Consider E to stand for ‘Environment’. It is a type parameter that takes yet another type parameter (which is why it is denoted E<_>). This means I could use List or Set, but not Integer as the type parameter value for E, since List and Set take another type parameter while Integer does not. You might think of the Functor interface as ‘applying the given function within the environment’.
We might write an implementation like this:
class ListFunctor implements Functor<list> {
public <A, B> List<b> fmap(Function<A, B> f, List<a> list) {
// todo: apply the given function on all elements in 'list' and return the result
}
}In general discussion, we would call this the list functor, simply because the value for the environment has been applied. In Runar’s article, he was talking about the Callable functor; yet another environment. There are many possibilities for the environment here; List and Callable are but two.
Let us not forget the laws :) Just like all implementations of CharSequence have laws to obey, so do all functors. They are called identity and composition.
Remember the Function interface? Here is an implementation:
class Identity<a> implements Function<A, A> {
public A f(A a) { return a; }
}If we are given an implementation of Functor – which I will call f – then it must satisfy f.fmap(new Identity(), x) is equivalent to x (for any value of x). So that’s the identity law out of the way. Mapping the identity function across a functor yields the same value.
The law of composition is a little less friendly when it comes to expressing it in Java so I will refrain :) While it is an important part of making up the concept of a functor, it may be best to defer this final piece of the puzzle for now.
For completeness, I will state the law using a shorter syntax, but if this is foreign or worrying, then please ignore it: f.fmap(a compose b, x) is equivalent to f.fmap(a, f.fmap(b, x)) (for any value of a, b and x – a and b are Function objects).
That’s all there is to a Functor. If you use the map function on lists or perhaps the map method on scala.Option, then you are using one specific instance of a functor, since these functions/methods satisfy the conditions for a functor. Even throwing an exception is using a specific functor! Perhaps that can be explained another time :)
I should also add that when referring to a functor (unqualified), we are referring to a covariant functor. Other types of functors include contra-variant and invariant functors. We can talk about those another day :)
Next: Just What the Flip is a Monad?
Questions?
In the spirit of yesterday’s post that denoted the Functor Laws using Reductio, I will also give the Monad Laws. Before I do however, here is an example use of the FunctorLaws object that runs 600 unit tests when testing a Functor implementation for scala.Option[A], scala.List and finally, for the scala.Either[A, _] functor just to make it a bit quirky and probably confuse a few of you (in that case, ignore it for now!) :)
val prop_OptionIdentity = identity[Option, Int]
val prop_OptionComposition = composition[Option, Int, String, Long]
val prop_ListIdentity = identity[List, Int]
val prop_ListComposition = composition[List, Int, String, Long]
val prop_EitherIdentity = identity[Apply1Of2[Either, String]#Apply, Int]
val prop_EitherComposition = composition[Apply1Of2[Either, String]#Apply, Int, String, Long]
// OK passed 100 tests. (appears 6 times -- once per property)…and the obligatory Monad Laws follow (import statements omitted this time, but they are the same as previous)…
object MonadLaws {
def leftIdentity[M[_], A, B](implicit m: Monad[M],
am: Arbitrary[M[B]],
aa: Arbitrary[A],
ca: Coarbitrary[A]) =
prop((a: A, f: A => M[B]) =>
m.bind(f, m.unit(a)) === f(a))
def rightIdentity[M[_], A](implicit m: Monad[M],
am: Arbitrary[M[A]]) =
prop((ma: M[A]) => m.bind((a: A) =>
m.unit(a), ma) === ma)
def associativity[M[_], A, B, C](implicit m: Monad[M],
am: Arbitrary[M[A]],
ca: Coarbitrary[A],
cb: Coarbitrary[B],
amb: Arbitrary[M[B]],
amc: Arbitrary[M[C]]) =
prop((ma: M[A], f: A => M[B], g: B => M[C]) =>
m.bind(g, m.bind(f, ma)) === m.bind((a: A) => m.bind(g, f(a)), ma))
}Woot! Woot!
Many people struggle to understand those fluffy things called Monads and why they are important. I’m not going to attempt to alleviate this to a large degree, but I have had a recent success with a friend in having them attempt to write a familiar Scala function as a method. That is, the [List.flatten](http://www.scala-lang.org/docu/files/api/scala/List$object.html#flatten(List[List[A]])) function, which simply takes a List of List of some type A and returns a List[A]. It does this by concatenating all the lists together. I think most people are familiar with this function and have a good mental model of how it works. If this is the case and you are less confident about List.flatMap, then I hope to bring a point to your attention that might help you bring it home.
If you take a look at List.sort, you see it takes a function (A, A) => Boolean. This is because the type parameter to List is ‘just any A’. It would be nice if it was ‘any A, so long as it has defined order’. That way, you can just call list.sort and be done with it. This would require the creation of a new class with a more restricted type parameter; for example, you might pass the function at list creation time, like you do with a TreeMap.
Imagine writing List.flatten on the List[A] class as a method using the same technique. You wouldn’t be able to, since the method belongs on a List[List[A]]. You’d need to write the method such that it takes an argument: A => List[A] before you could then call flatten. When you have a List[List[A]], you’d just call this method with the identity function x => x to obtain your resulting List[A]. Here is how the method would look:
def flatten(f: A => List[A]): List[A] = ...Guess what?! This method is flatMap! Let’s ignore the fact that the Scala API is significantly broken, including the List.flatMap method using Iterable in place of List here. Notice though, that flatMap is actually generalised by taking another type parameter, so we have just invented an unnecessarily specialised version of flatMap. Let’s fix it:
def flatten[B](f: A => List[B]): List[B] = ...Woot woot! In other words, flatten(list) is equivalent to list flatMap (x => x). Furthermore, this should hold for more than just list, but for other type constructors too (sadly, Option is missing a flatten function: Option[Option[A]] => Option[A]). This is a special relationship that all monads have (join is a synonym for flatten and bind is a synonym for flatMap):
join = bind idWe can express this using Reductio (the Scala API of course!):
val prop_flat = prop((t: List[List[Int]]) => List.flatten(t) == t.flatMap(x => x))
// OK passed 100 tests.I hope this helps. If it doesn’t, ask a question or ignore my ranting :)
A somewhat intricate and extremely useful code snippet using Reductio for testing the laws of any Functor instance (note that the Functor type is part of Scalaz):
import reductios.Property._
import reductios.Arbitrary
import reductio.Coarbitrary
import reductios.Arbitrary._
object FunctorLaws {
def identity[F[_], A](implicit f: Functor[F], af: Arbitrary[F[A]]) =
prop((fa: F[A]) => f.fmap((a: A) => a, fa) === fa)
def composition[F[_], A, B, C](implicit f: Functor[F],
af: Arbitrary[F[A]],
ac: Arbitrary[C],
cb: Coarbitrary[B],
ab: Arbitrary[B],
ca: Coarbitrary[A]) =
prop((fa: F[A], h: B => C, i: A => B) =>
f.fmap(h compose i, fa) === f.fmap(h, f.fmap(i, fa)))
}From http://www.news.com.au/comments/0,23600,23907216-462,00.html on the recent price rise by ABC Learning Centres (i.e. child care):
ABC Learing centres have now increased there fees three times since early 2007. There justification for these raises in no way benefit the children in they’re care or they’re staff!.
The Applicative Functor pattern is an incredibly powerful abstraction. I recently added it to a branch of Scalaz. However, it would be nice if I could alter the fixity of functions so that the parentheses below are not required to make the expression right-associative.
val add = (a: Int) => (b: Int) => (c: Int) => a + b + c
val none: Option[Int] = None // Grrr Scala
// Some(24)
println(Some(7) <*> (Some(8) <*> (Some(9) > add)))
// None
println(Some(7) <*> (none <*> (Some(9) > add)))
// List(87, 88, 89, 91, 92, 93)
println(List(1, 2, 3) <*> (List(77) <*> (List(9, 13) > add)))Having to write that silly none value is annoying too. At the very least a none function would suffice:
def none[A]: Option[A] = NoneThat way. I could use none[Int] and be done with it.
Still, this pattern is a nice tool to use and I will surely be using it in the future.
When disciplined programmers write unit tests, they often make reference to the fact that their tests provide a means of documentation the software that it is testing. This documentation is more appropriate than what would otherwise be informal and potentially ambiguous comments using English. Take the simple example of adding two numbers. We might document using informal language:
/**
* Adds the two arguments.
*
* @param a Add this argument to the other one.
* @param b Add this argument to the other one.
* @return The sum of the two arguments.
*/With unit tests, we might instead write something more formal and unambiguous:
{.Java} assertEqual(add(2, 2), 4) assertEqual(add(4, 3), 7) … so on
It might be argued that both these forms of documentation complement each other. After all, while the unit tests have less room for misinterpretation, they are incomplete; for example, what about add(88, 37)? The English description makes up for this shortcoming.
We could reword our English to be a little more succinct:
~{.Java} /** * Passing 0 as one argument returns the other argument, * otherwise, the result is the same as subtracting 1 from one argument and * adding 1 to the other argument then passing those values instead. * e.g. add(2, 8 ) is the same as add(1, 9) and so on until one of the arguments reaches 0. */
Wouldn’t it be nice if we could express this formally in unit tests? You can, read on.
While this example is trivial, it scales in proportion to the amount of discipline that the programmer is willing to exercise by controlling side-effects in their program. If we write our programs such that most of our methods retain the property of referential transparency, we can use this advanced method of tests as documentation. When we refactor our code to make tests easier to write, it is often the case that we are doing exactly this anyway. Win win!
We’ll give a slightly less trivial example next, but not so trivial that it takes away from the important points. In fact, let’s unit test a specific part of the Java Collections library – the java.util.Collections.reverse method. There are various ways of testing this method and we will choose one here that serves to illustrate the point of unit tests as documentation.
The reverse method can be described as follows:
For the empty list, then reversing this list is always the same list
For the list with one element, then reversing this list is always the same list
For any other two lists (let’s call them ‘a’ and ‘b’), then appending b to a then reversing will yield the same list as reversing a, then appending the result to the reverse of b. Since this statement is a little convoluted, let’s write it with some pseudo-Java syntax notation: (a.append(b)).reverse() == b.reverse().append(a.reverse())
It is an interesting observation here that we have completely specified the reverse method. That is, under some reasonable assumptions, it is not possible to write a method that is not equivalent to reverse that also satisfies our statements above. This is the ultimate form of code documentation!
We will ignore the first statement for the sake of interest and verbosity and focus on expressing the other two. This is because statements 2 and 3 have free variables, while statement 1 is merely an assertion that does not illustrate any interesting points. Let us start with the second statement and articulate it using Reductio:
Property p2 = property(arbInteger, new F<Integer, Property>() {
public Property f(Integer i) {
return prop(single(i).equals(reverse(single(i))));
}
});That pretty much sums up statement 2 doesn’t it? What about statement 3:
Property p3 = property(arbLinkedList(arbInteger), arbLinkedList(arbInteger), new F2<LinkedList<integer>, LinkedList<integer>, Property>() {
public Property f(LinkedList<integer> a, LinkedList<integer> b) {
final LinkedList<integer> x = reverse(append(a, b));
final LinkedList<integer> y = append(reverse(b), reverse(a));
return prop(x.equals(y));
}
});Yep. Notwithstanding the absence of statement 1, we have completely specified the behaviour for the Java Collections.reverse method. We have exhaustive and formal documentation instead of one or the other as we traditionally do. What an improvement!
That’s not hard either. How many unit tests do you want to run? By default, Reductio will run 100 unit tests per Property declaration. You can adjust this and various other factors about how your unit tests are executed. If you want to take the default, then a few more lines of code are enough to do just that:
list(p2, p3).foreach(new Effect<property>() {
public void e(Property p) {
summary.println(p.check());
}
});If you run this line of code, you will see the result of your 200 unit tests on the standard output:
OK, passed 100 tests.
OK, passed 100 tests.Is that too magical for you? Don’t believe me? Want to see it fail? OK, let’s fail it. In the expression of statement 3, change the line b.addAll(a) to a.addAll(b) and run again. What did you see? Here is what I saw:
OK, passed 100 tests.
Falsified after 4 passed tests with arguments: [[3, 2, -3, 4, -3],[2, -3, 4, -3]]Yep, it failed alright :) When those two list values are used as our free variables, the property is false and the unit test fails.
import fj.Effect;
import fj.F;
import fj.F2;
import static fj.data.List.list;
import static reductio.Arbitrary.arbInteger;
import static reductio.Arbitrary.arbLinkedList;
import static reductio.CheckResult.summary;
import reductio.Property;
import static reductio.Property.prop;
import static reductio.Property.property;
import java.util.Collections;
import static java.util.Collections.singletonList;
import java.util.LinkedList;
public class ListReverse {
public static void main(String[] args) {
Property p2 = property(arbInteger, new F<Integer, Property>() {
public Property f(Integer i) {
return prop(single(i).equals(reverse(single(i))));
}
});
Property p3 = property(arbLinkedList(arbInteger), arbLinkedList(arbInteger), new F2<LinkedList<integer>, LinkedList<integer>, Property>() {
public Property f(LinkedList<integer> a, LinkedList<integer> b) {
final LinkedList<integer> x = reverse(append(a, b));
final LinkedList<integer> y = append(reverse(b), reverse(a));
return prop(x.equals(y));
}
});
list(p2, p3).foreach(new Effect<property>() {
public void e(Property p) {
summary.println(p.check());
}
});
}
static <a> LinkedList<a> single(A a) {
return new LinkedList<a>(singletonList(a));
}
static <a> LinkedList<a> reverse(LinkedList<a> as) {
LinkedList<a> aas = new LinkedList<a>(as);
Collections.reverse(aas);
return aas;
}
static <a> LinkedList<a> append(LinkedList<a> as1, LinkedList<a> as2) {
LinkedList<a> aas = new LinkedList<a>(as1);
aas.addAll(as2);
return aas;
}
}Disciplined programmers write tests while developing code. Some even refactor their tests when certain situations arise. Imagine this one. You have just written a method that takes two integer arguments, adds them and subtracts seven before returning the result.
Your code might look like this:
int addThenSubtract7(int x, int y) {
return x + y - 7;
}When you test this code – either before, during or after you write the method above – you will likely write tests that exhibit some property about the method under test. For example, when one argument is the negation of the other, you will always get back -7.
assertEquals(-7, addThenSubtract7(0, 0));
assertEquals(-7, addThenSubtract7(1, -1));
assertEquals(-7, addThenSubtract7(2, -2));
assertEquals(-7, addThenSubtract7(3, -3));
assertEquals(-7, addThenSubtract7(4, -4));
assertEquals(-7, addThenSubtract7(5, -5));You might refactor in this scenario:
assertTrue(negationBecomesNegative7(0));
assertTrue(negationBecomesNegative7(1));
assertTrue(negationBecomesNegative7(2));
...
public boolean negationBecomesNegative7(int a) {
return addThenSubtract(a, -a) == -7;
}Indeed, you might use a loop for your input values:
for(int i = 0; i < 100; i++) {
assertTrue(negationBecomesNegative7(i));
}
...There are other properties about the method addThenSubtract7. For example, if you switch the arguments, the result is unaffected. In fact, this property comes up a fair bit so it even has a name; commutativity. You could come up with a similar scenario as that described above through a process of repeating assertions with different values, refactoring a bit and generally trying to test as rigorously as possible with minimal effort and permitting future maintainability of both your code and your tests.
Eventually, you will have written properties about your method such that there is no reason to write any more properties, since they would be implied by your existing properties. For example:
You could write a test for addThenSubtract7(0, anyValue) results in anyValue - 7.
Then you could write a test for commutativity; addThenSubtract7(someX, someY) results in the same value as addThenSubtract7(someY, someX).
Now, is there any point writing a test for addThenSubtract7(anyValue, 0) results in anyValue - 7? Isn’t this implied by the test for commutativity? Right, this test would be redundant.
Ultimately, you could aim for an unambiguous specification of your method under test. However is there a nicer way to write all these tests?
Going back to the first property negationBecomesNegative7, don’t you really just want to say this and then let the rest be taken care of by clever automation?
for all int values named a. then addThenSubtract7(a, -a) == -7This is the job of Automated Specification-based Testing such as that which is implemented by Reductio for Java. Reductio allows you to write the above expression using standard Java syntax:
Property p = property(arbInteger, new F<integer, Property>() {
public Property f(final Integer a) {
return prop(addThenSubtract7(a, -a) == -7);
}
});What is going on here? We are passing in our generator of arbitrary integer values (arbInteger), then an anonymous inner class that asserts our property for our free variable (the one called ‘a’).
OK, it can’t be this easy can it? No, sorry, it can’t. There is an enormous of work to do next. Ready, here it is:
p.check();With all that heavy lifting taken off you by the test automation, you should now have plenty of time and energy to get on with delivering your software to your client or maybe reading news blogs if that is what you prefer :)
When you run the test automation, you receive a result of success after running 100 (by default – adjustable of course) tests or you receive a failed result with a counter-example. That is, you receive a value for your free variable (a) for which the property was not true.
Does it stop here? I mean, this is great and everything, but surely there’s not more help that can be provided by clever test automation software? There are a couple more clever things that can be done.
First is the shrinking of a counter-example. Imagine there was a bug in the addThenSubtract7 method and you received a counter-example of 1789234. What’s so special about this number? Well, that depends on the bug, however, maybe this is just the first counter-example that was found. Imagine, however, that the bug also exhibited itself (i.e. the property fails) with a counter-example of 2. Isn’t this a more useful counter-example? Wouldn’t you prefer that this one was reported and not that big, insignificant number?
So that’s another great feature of test automation; it can report back to you useful counter-examples in the event of a bug. When you perform manual testing as above, you might remove a couple of your assert methods to help narrow down the bug. This is the hard way! This very act can be automated.
Imagine you wrote this property (a + b == a - b):
final Property p = property(arbInteger, arbInteger, new F2<integer, Integer, Property>() {
public Property f(final Integer a, final Integer b) {
return prop(a + b == a - b);
}
});It turns out that this property is true for some values such as a == 0 and b == 0, but false for others:
a = 1, b = 15
a = 147, b = 92582
a = 5923, b = 12
But which of these counter-examples is going to be most useful to you, the tester? Any of the above? How about this counter-example: a = 0, b = 1? Isn’t this more useful to you than any of those above?
Good test automation software will report a reasonably small counter-example in the event of the falsification of a property.
OK, is there more? Yes sorry to keep your attention. Test automation software will also generate instances of an interface for you. That’s right, you can quantify across an interface in your property expressions. This is a bit like mocking, except not so manual; you just pass in the arbitrary generator (Reductio provides them of course) just as we did above and you can wipe your hands clean of the remaining manual effort otherwise.
You might want to write a property where you say something like, “for all instances of my interface or class, then such and such…”. This might be an instance of the HttpServletRequest interface or perhaps one of your own classes. The good part is, no more manual mocking.
You can read the Reductio Manual or perhaps look at some code examples. If you’re a fan of the coming Java 7 BGGA closure syntax, you might prefer these code examples. Perhaps you’re into higher-level programming and prefer Scala code examples. Whichever you choose, please feel free to jump on the Reductio mailing list or chat channel and ask your question, no matter how silly it seems to you.
Re: Your insistence on distinguishing unit testing and integration testing.
You make the distinction between unit testing and integration because you are a sloppy programmer. You throw side-effects around like a 5 year old in a play pen. You do not care for intellectual discipline in your thinking process. Nor do you care for high-level abstraction or composition of your software. Instead, you insist on this dogmatic “test driven” nonsense. You do this because you are married to the FORTRAN family of programming languages. Your so-called integration tests exist because you have implicit free variables in your equations like a ‘good little imperative programmer’. If you did decide to apply discipline and consider your side-effects, you’d see no distinction between unit testing and integration testing. I realise that this possibility escapes your feeble and narrowed mind at this stage of the socratic midwife process.
When you do unit test, you’re using an awfully impoverished method. I mean, “assert this and assert that”. Give me a break! You think this is going to “drive” something? Anything? OK, it drives me bonkers to think that you insist on spreading mythological, pseudo-scientific, fanatical bullshit (excuse the term, but it is most accurate) and have followers repeat said myths in such an obedient I-cant-think-for-myself fashion. You think you’re contributing to the “design” and “quality” of your software? How mistaken you are and what empathy I feel for you.
I implore you to retract your silliness and take seriously the charge that you are a sloppy programmer (evidence forthcoming). Your dependence on “agile this” (I play A grade squash, I’m perfectly agile, thanks) and “test drive that” are entirely dependent on an existing sloppy form of programming. Furthermore, these workarounds not only rest on a flawed premise, but they are extremely diluted anyway. Even with the given silly premise you can significantly improve! But I won’t tell you how, no not yet. First you must prepare for an act of apostasy, which I understand can be very traumatic. So I can’t help you until then, but in the meantime, I kindly ask that you stop imposing your silly ideas on me, because yes, they are silly.
See you on the other side.
When I saw the schedule for JAOO 2008, two names stood out for me; Erik Meijer (Haskell) and Don Syme (F#). My second thought was “why are the smart guys in Microsoft Research?”. I don’t really have an answer to that, but it’s an interesting question.
Meijer opened with a 1 hour talk on the software crisis and how we can solve it. A quick glance around the room quickly confirmed my suspicion that much of the audience was lost with the lambda-notation and various other squiggles on his slides, but deep inside, I could feel myself pushing him to continue. He had hit the nail right on the head with how to solve the so-called software crisis (perhaps an alarmist name, but there is a phenomenon of some sort).
I was disappointed that I could not disagree with Erik – not even in the slightest detail. When I saw him emphasising his displeasure with Haskell’s unsafePerformIO, I thought I had him. This was my opportunity to disagree with someone smarter than myself. But it wasn’t to be, he answered my question with almost exactly the same rhetoric that I would have used myself. I just think his emphasis on unsafePerformIO was because he knew he was standing in front of mostly Java/C# users. Perhaps that’s the lesson to learn; target your audience the way he did. A consolation prize at the very least.
From the introduction, I knew I was in for a great ride, however, I believe there were only two types of people in theatre during Meijer’s speech:
those who understood what he was saying in his limited time slot
those who didn’t quite understand but really want to, whether they know that fact or not
It is this second point that I wish to elaborate. I found many speakers thereafter had a common theme in trying to resolve some sort of crisis in software development; Dave Thomas and some of the problems he described, Rob Martin and his Clean Code, Michael Feathers and his Unit Testing and even Martin Fowler and his Enterprise Patterns. With some deeper thought, you can see that these speakers are – in some vague sense – highlighting the fact that there exists some kind of critical problem and each his trying to put forward his/her answer. Many of these speakers described the same problem, but then gradually and sometimes quickly diverged from what I think is the correct answer. Meijer nailed it guys! No seriously, the solution is in his slides and his exaggerated body language.
I know many people think Meijer’s solution and mainstream topics are disjoint and not unifiable. How could Meijer’s funny lambda symbols have any bearing on Fowler’s enterprise pattern or Feathers’ insistence on not testing that (dang side-effecting) database? No, there is no fence to jump. All these guys are just acknowledging the same problem in some vague notion and looking for an answer, believing they have found it. It is the realisation of the unification of this funny mathematical stuff with the euphemistic terms like “TDD” and “Agile” that brings the greatest reward. Is it not a big enough hint that the in-crowd is reinventing some of this stuff in a diluted and not-so-useful form?
Rob Martin, yes, the world is counter-intuitive and your analogy to Quantum Mechanics is perfect. However, what would Einstein say to your shunning of the application of thought experiment? You nailed the problem, but the solution was slightly misdirected. Meijer was pointing you to the answer. The theoreticians have it right and in the most practical sense; is history not a good indicator? No Rob, the jury is not in; you’ve screwed up. Are you open to this possibility? Any professional would be ready to accept an unheard argument, right?
If, as a participant of JAOO 2008, you were to take the time to truly and deeply understand the topic that Meijer was alluding to, then I give you an unreserved promise of a moment of realisation that will tingle your spine, fill your eyes with water and euphoria (you know that feeling right?) that far supersedes any other moment that you may have had in your programming journey so far. I say this with utmost confidence. And here’s the thing, there is an entire community of people waiting to help you to understand that funny lambda symbol, those strange arrows, what it means to write code from types, what code documentation and verification truly means and much more. We love answering your questions! The scientific community truly embraces ignorance; no really it does. Please don’t be afraid to express it; learning is fun.
So here’s my little contribution to the progress of software development; I’ll happily answer your questions about Meijer’s topic right here or by private email if you prefer (however, I don’t have the slides, so you’ll have to be specific in your query). Hopefully then, you can open JAOO 2009 and I can indulge myself by disagreeing with you in some way! :)
From a fellow programmer who wants to solve these problems too so please ask questions.
So you wanna know how to test Java’s equals/hashCode huh?
Here is a true statement that should hold for any equals and hashCode implementation:
forall x. forall y. x.equals(y) => x.hashCode() == y.hashCode()
You can read => as implies. So if x equals y, then this implies that the hash code of x is equal to the hash code of y. This is called logical implication and is often written in English as “if p then q”, for some p and q, just like I did in the previous statement. Easy peasey eh?
How might we test the equals and hashCode implementation of MyClass? If we were using JUnit (or some other non-automated test tool):
assertEqual(new MyClass(7, "abc").hashCode(), new MyClass(7, "abc").hashCode());
assertEqual(new MyClass(42, "CBA").hashCode(), new MyClass(42, "CBA").hashCode());
... etc. etc.What we would really like to say is something like:
I assert that for any two equal instances of
MyClass(call them x and y), then the hashCode of x is equal to the hashCode of y. Dear test tool (Reductio!), please try your best to show me why this is false if you find it to be so.
Well, that’s just an English way of saying the logical implication statement above, right? We could write this statement in Java (boiler-plate omitted):
Property p = property(arbMyClass, arbMyClass, { MyClass m1, MyClass m2 =>
bool(m1.equals(m2)).implies(m1.hashCode() == m2.hashCode()) })Reductio is open source (BSD) software that provides some very clever ideas adapted from QuickCheck. In particular, Reductio allows you to write algebraic properties about your software and the software then attempts to falsify these properties using automation of function domain value generation. Reductio can run 1000 unit tests in 4 or 5 lines of code, and that is Java code! (No, I am not kidding; really take a look at some of the code examples)
Reductio also provides shrinking of counter-examples in the event of proving a property false; for example, a + b == a - b is not always going to be true (for all values of ‘a’ and ‘b’), but would you like Reductio to provide the counter-example a = 1934, b = 4571? I think you’d prefer a smaller counter-example such as a = 1, b = 1 right? I would too :) By providing the smallest reasonable counter-example, Reductio makes it easier to debug your code in the event of finding fault.
Another extremely useful feature of Reductio is automated mocking. That is to say, Reductio can generate implementations of an interface for you so long as you provide the mapping from one or more transformations (this exploits a programming pattern called a Functor) to your type. Doing so is guaranteed to be a straight-forward task for the user (so straight-forward that you could automate it with reflection; an add-on feature perhaps?). This allows you to quantify across interface types. For example, you might state a property about your software using some interface, but you assert that the property holds regardless of the implementation of the interface. Reductio will generate hundreds of implementations if you like! All automated of course ;)
Reductio makes it trivial to write generators for user-defined types (again, another potentially automated task that requires Java’s meta-programming facility ala reflection), however, Reductio also provides many existing implementations. Following is a non-exhaustive list.
If you’re into robustness in the verification of the correctness of your Java software, take a look at Reductio. http://reductiotest.org/
Boolean
Byte
Character
Double
Float
Integer
Long
Short
String
StringBuffer
StringBuilder
ArrayList
BitSet
Calendar
Date
EnumMap
EnumSet
GregorianCalendar
HashMap
HashSet
Hashtable
IdentityHashMap
LinkedHashMap
LinkedHashSet
LinkedList
PriorityQueue
Properties
Stack
TreeMap
TreeSet
Vector
WeakHashMap
ArrayBlockingQueue
ConcurrentHashMap
ConcurrentLinkedQueue
CopyOnWriteArrayList
CopyOnWriteArraySet
DelayQueue
LinkedBlockingQueue
PriorityQueue
SynchronousQueue
Date
Time
Timestamp
BigDecimal
BigInteger
ADDED Arbitrary instance for functions.
FIXED ConsoleReporter updated according to changes in Scala’s printf method.
CHANGED Properties and Commands now extend Prop, so they can be used as single properties.
ADDED Properties.include for grouping properties.
ADDED Prop.main for convenient test execution.
CHANGED Fixed Arbitrary for Option so that None does not occur so often.
ADDED Arbitrary instance for scala.Either (Added in Scala 2.7.1-RC2).
ADDED Existential quantifier in Prop.scala.
I have a situation that I am wondering how others may have solved. I have an open source (BSD) project whose copyright is owned by the company I work for. Another person, working for another company (in another country!) wishes to contribute to this project, which I think is great.
How is the ownership of copyright usually sorted out in these situations? Is it shared by both parties? Does each party maintain copyright to their respective contributions? Does the party wishing to contribute sign over copyright ownership? Is there another alternative that I haven’t thought of? Surely this situation comes up a lot; how is it usually handled?
How funny :) Laziness is unpredictable!
I lurk on the Haskell Cafe mailing list and eager evaluation is often the solution to reliability or performance problems: laziness is unpredictable.
In the spirit of esoteric code snippets like this one, I thought I’d put my two bob in :)
I have written the Levenshtein Distance algorithm using Scala below. The Levensthein Distance algorithm is a Dynamic Programming Algorithm (DPA). This implementation is a little different to the Python one (which creates the arrays explicitly and fills them using loops):
The code more closely represents the mathematical definition of the algorithm
The code is easier to reason about because the destructive updates occur behind the scenes (in the memoisation library)
The code below requires a third party library (Scalaz) note that Scalaz comes with demo code including the levenshtein distance and other DPAs
The code has a better complexity than the typical loopy version by using lazy evaluation (notice that ‘c’ is not always evaluated)
While the code memoises with an array, you could use say, a map and save some space as well
The code builds the call stack as it traverses the matrix (the loopy one does not)
import scalaz.memo.Memo
import scalaz.memo.SizedMemo.arraySizedMemo
object Levenshtein {
def levenshtein[A](x: Array[A], y: Array[A]): Int = {
val im = arraySizedMemo
val m = im[Memo[Int, Int]](x.length + 1)
// the call matrix
def mx(i: Int, j: Int): Int = if(i == 0) j else if(j == 0) i else {
def f = (n: Int) => im[Int](y.length + 1)
val a = m(f)(i - 1)(mx(i - 1, _))(j) + 1
val b = m(f)(i - 1)(mx(i - 1, _))(j - 1) + (if(x(i - 1) == y(j - 1)) 0 else 1)
lazy val c = m(f)(i)(mx(i, _))(j - 1) + 1
if(a < b) a else if(b <= c) b else c
}
mx(x.length, y.length)
}
def main(args: Array[String]) =
println(levenshtein(args(0).toCharArray, args(1).toCharArray))
}To run this code:
$ wget http://projects.workingmouse.com/public/scalaz/artifacts/2.4/scalaz.jar # download Scalaz 2.4
$ scalac -classpath scalaz.jar Levenshtein.scala # compile
$ scala -classpath .:scalaz.jar Levenshtein algorithm altruistic # find the distance!
<strong>6</strong>Rabbi Yisrael Rosen, director of the Tsomet Institute says:
All of the Palestinians must be killed; men, women, infants, and even their beasts.
Oh really? I didn’t know that! Thanks for letting me in on it.
Rosen asserted that there is evidence in the Torah to justify this stand.
Uh oh, an hallucinabating Rabbi.
Rosen, an authority able to issue religious opinions for Jews…
You mean, people who do not possess the ability to think independently? I had a few of those commenting on my blog recently!
… wrote that Palestinians are like the nation of Amalekites that attacked the Israelite tribes on their way to Jerusalem after they had fled from Egypt under the leadership of Moses.
Did you learn that at a nativity scene when you were being indoctrinated as a child?
He wrote that the Lord sent down in the Torah a ruling that allowed the Jews to kill the Amalekites,…
Oh the Lord did that? That’s OK then.
The true outrage is that most of those authorised to issue Jewish religious opinions support the view of Rabbi Rosen, as confirmed by Haaretz newspaper.
Well it has to be right then! I bet the aforementioned commenters agree too, so it’s super spectacularly right! Oh wait, the truth value of the proposition was never open for analysis. Sorry Authority.
The danger of these religious opinions lies in the fact that the religious authorities issuing them have wide respect among religious Jewish youth.
You mean, your children subscribe to views of self-appointed authority without question? Hey, we have children that do that too! Does your indoctrination scheme masquerade as an education system like ours?
Wasil Taha, Arab Knesset member from the Tajammu Party led by Azmi Bishara, says that these religious opinions lead to the committal of crimes… Taha holds that the sectors of the Palestinian population most likely to be harmed by these religious opinions are those living in the various cities populated by both Jews and Palestinians, such as Haifa, Jaffa, Lod, Ramleh and Jerusalem.
I feel sick, but not as much as the hallucstibating Rabbi appears to be.
Burning question: Do Atheists have cause to be angry, despite not bearing arms to express this anger (due to a more grounded sense of morality?)?
I’m assuming you’re familiar with traditional mainstream unit testing techniques such as that purported by JUnit, NUnit and so on. Automated unit testing automates the generation of elements to apply a function to, in light of a stated algebraic property of that function. This is in contrast to traditional unit testing, where a proposition is made about the application of a function to specific elements of the domain.
Take, for example, the java.lang.String.endsWith function. Using JUnit, we might write:
assertTrue("abc".endsWith(""));
assertTrue("abc".endsWith("bc"));
assertFalse("abc".endsWith("ab"));
// ...and so onUsing automated testing, we might instead write something like this English statement:
For any two Strings (x and y), then
(x + y).endsWith(y)istrue.
Here is that same statement for formally:
∀ x. ∀y. (x + y) endsWith yNote that we don’t have to declare x or y to be elements of the set java.lang.String, since the type system proves this fact. Note also that we assume correctness of + as a premise of the proposition, while the proposition itself is open (that is, this is the statement we are trying to disprove).
After putting forward the above open statement, the test software would automatically attempt to falsify (note that this is different to “prove”) this proposition by generating arbitrary values. As a user, you may wish to skew the distribution of these values, adjust the amount of attempts at falsification and various other configuration values. Many have reasonable defaults, such as when generating integer values, include 0, 1, -1, max, min, max-1 and min-1 and typically make 100 to 500 attempts at falsification by default (in critical code, for example, you may turn this up).
This concept of automated testing did not originate with ScalaCheck. In fact, I have recently noticed the mainstream fraternity have started replicating watered down versions of automated testing (note that it is extremely cumbersome to achieve effectively in mainstream languages). Indeed, advanced programming concepts often take a lot of time to bubble down from research/academia to mainstream in a typically diluted form. This concept originated from a paper titled QuickCheck: Automated Specification-Based Unit Testing. Note that JUnit et. al. is not automated, but (very) manual testing.
The original language, Haskell, has language features called type-classes and higher-order functions, as does Scala. Both of these are required language features to use automated testing effectively, though it is possible to achieve in a lesser form in less useful languages. Note that Java does not have either of these language features. Are we hosed? No!
Take a look at this source file, which states our property about endsWith using Scala (see endsWithProperty):
// CheckString.scala
import org.scalacheck.Prop._
import org.scalacheck.ConsoleReporter.testStatsEx
import org.scalacheck.Test.check
object CheckString {
// Here is the property
val endsWithProperty = property((x: String, y: String) =>
((x + y) endsWith y)
)
// A List of properties - we only have one at the moment.
val tests = scala.List(
("endsWithProperty", endsWithProperty)
)
// Run all our properties with the default configuration.
// Are our properties false?
def main(args: scala.Array[String]) =
tests foreach { case (name, p) => testStatsEx(name, check(p)) }
}You can run this source file by downloading ScalaCheck-1.2.jar and compiling it with the Scala compiler.
$ scalac -classpath ScalaCheck-1.2.jar CheckString.scalaDoes our stated property falsify?
$ scala -classpath .:ScalaCheck-1.2.jar CheckString
+ OK, passed 100 tests.No! After 100 unit tests, the stated property cannot be shown to be false. We might assume its correctness now. Note that this is java.lang.String that we are testing here running on a Java Virtual Machine, not some other esoteric String – yes, the one you use in your Java enterprise applications ;) You can apply this technique to any Java type.
How about this proposition:
For any two Strings (x and y), then
x.reverse.startsWith(y.reverse))is equivalent (in truth) tox.endsWith(y).
Again, startsWith is assumed correct as a premise of the proposition (or theorem). Can the statement be falsified by the test automation?
// CheckString.scala
import org.scalacheck.Prop._
import org.scalacheck.ConsoleReporter.testStatsEx
import org.scalacheck.Test.check
object CheckString {
val endsWithProperty = property((x: String, y: String) =>
((x + y) endsWith y)
)
// Can you falsify this?
val endsWithProperty2 = property((x: String, y: String) =>
x.endsWith(y) == x.reverse.startsWith(y.reverse))
val tests = scala.List(
("endsWithProperty", endsWithProperty),
("endsWithProperty2", endsWithProperty2)
)
def main(args: scala.Array[String]) =
tests foreach { case (name, p) => testStatsEx(name, check(p)) }
}Well, can it? Oh come on, please tell me! :)
$ scala -classpath .:ScalaCheck-1.2.jar CheckString
+ OK, passed 100 tests.
+ OK, passed 100 tests.No. We have now successfully executed 200 unit tests so we may be prepared to declare satisfaction with the correctness of the propositions under analysis. Note again, that we have not proven these properties to be true (we did prove others to be true using the type system). In fact, doing so for the general program is equivalent to solving the halting problem, so good luck if you’re looking for something more rigorous ;)
You may have observed that I called a method on String that does not exist in the Java API – reverse. In Scala, you can add methods to objects in a type-safe manner. The reverse method is added by default in the Scala runtime. In Java, you might instead have written reverse as a static method of a StringUtils class or something. This fact does not negate the fact that we are still using the same ol’ java.lang.String that Java Jim is using next door.
The test automation supplied 100 String values for each of the two properties in an attempt to falsify; where did they come from? ScalaCheck includes an abstract type called [Arbitrary](http://scalacheck.googlecode.com/svn/artifacts/1.2/doc/api/org/scalacheck/Arbitrary.html) and an implementation for the String type is supplied by ScalaCheck. It is this that is used to generate String values. If we wish to generate values for our own types, we must write our own Arbitrary implementation for it.
I will state some properties now about java.util.LinkedList and its addFirst method. However, note that unlike java.lang.String, ScalaCheck does not include an arbitrary generator for linked lists, so we will have to write one. Luckily, generators are instances of what is known as a functor (also, a monad), so this task will be quite trivial. Let’s start with doing that.
We can generate arrays, since that ability comes with ScalaCheck, so we can use the map function (i.e. the essence of a functor) to take the generator for arrays to a generator for linked lists. Given an array, we can create a linked list using: new LinkedList[A](Arrays.asList(array)). This is precisely what the code below does using what is called a higher-order function inside the Arbitrary functor. You needn’t concern yourself with these advanced programming concepts in these demonstrations, but just acknowledge their existence and that the given code is trivial and it works.
import org.scalacheck.Arbitrary
import org.scalacheck.Arbitrary.arbitrary
import java.util.{LinkedList, Arrays}
object CheckLinkedList {
implicit def arbitraryLinkedList[A](implicit a: Arbitrary[A]): Arbitrary[LinkedList[A]] =
Arbitrary(arbitrary[Array[A]].map(array => new LinkedList[A](Arrays.asList(array))))
}Note the implicit declaration on the method. This is required, however, this language feature is very powerful and only a very lengthy discussion would do it justice, so we will say nothing more than it is required in this case, it is very powerful and Java has no equivalent (you can mildly emulate it with the singleton anti-pattern – another topic).
What properties can we state now about addFirst? How about for any list and any element, adding the element to the list adds 1 to its size? We call this property addsLengthOne below.
// CheckLinkedList.scala
import org.scalacheck.Arbitrary
import org.scalacheck.Arbitrary.arbitrary
import java.util.{LinkedList, Arrays}
import org.scalacheck.Prop._
import org.scalacheck.ConsoleReporter.testStatsEx
import org.scalacheck.Test.check
object CheckLinkedList {
implicit def arbitraryLinkedList[A](implicit a: Arbitrary[A]): Arbitrary[LinkedList[A]] =
Arbitrary(arbitrary[Array[A]].map(array => new LinkedList[A](Arrays.asList(array))))
val addsLengthOne = property((list: LinkedList[String], s: String) =>
list.size + 1 == { list.addFirst(s); list.size }
)
val tests = scala.List(
("addsLengthOne", addsLengthOne)
)
def main(args: scala.Array[String]) =
tests foreach { case (name, p) => testStatsEx(name, check(p)) }
}I’ve copied and pasted the boilerplate to get the tests running for the demonstration, but please feel encouraged to put this kind of code in its own function to avoid this repetition.
How did we go?
$ scala -classpath .:ScalaCheck-1.2.jar CheckLinkedList
+ OK, passed 100 tests.Yippee!!
We might state two more properties:
* For any list and any element (s), list.add(s) then list.get(0) will always yield s.
* For any list, any element (s) and any integer between 0 and list.length - 1 (n), then calling list.get(n) is equivalent to calling list.addFirst(s).get(n + 1).
$ scala -classpath .:ScalaCheck-1.2.jar CheckLinkedList
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.I have left off the code for the moment and I will give a complete example toward the end. Note that we have 300 passing unit tests – the code is around 25 lines (excluding the boilerplate to get the tests running).
At this point, we have given an unambiguous specification for addFirst. In other words, it is not possible to write a terminating function that does not satisfy these properties that is not equivalent to addFirst. However, this ignores the unfortunate potential for uncontrolled side-effects, which is an inherent property of Java (and Scala for that matter). We will assume it to be the case – no additional side-effects. It then follows that one additional benefit of automated testing is that we also obtain extremely valuable documentation for the function.
Consider being provided with:
* The type signature for addFirst (the properties which are proved).
* The three stated properties for addFirst.
Is there anything more useful to add in terms of documentation? Isn’t this unambiguous, highly readable specification more than you could possibly ask for? This is an interesting question to ponder, particularly in a more pure environment than the one we are discussing here, but I thought I would mention it anyway :)
I will state a property that is false, just to exemplify what happens. The idea is that it is extremely difficult (but not impossible – remember halting problem) to state a false property that ScalaCheck passes. I’m not going to look for a specific corner case that traditional unit testing is unlikely to pick up, but I encourage you to do so as an added exercise.
Instead, I will state an obviously false property; for any list and any element, adding the element with addFirst is equivalent to adding that element with addLast.
Here we go (note the fourth property – thisIsFalse):
// CheckLinkedList.scala
import org.scalacheck.Arbitrary
import org.scalacheck.Arbitrary.arbitrary
import java.util.{LinkedList, Arrays}
import org.scalacheck.Prop._
import org.scalacheck.ConsoleReporter.testStatsEx
import org.scalacheck.Test.check
object CheckLinkedList {
implicit def arbitraryLinkedList[A](implicit a: Arbitrary[A]): Arbitrary[LinkedList[A]] =
Arbitrary(arbitrary[Array[A]].map(array => new LinkedList[A](Arrays.asList(array))))
val addsLengthOne = property((list: LinkedList[String], s: String) =>
list.size + 1 == { list.addFirst(s); list.size }
)
val getZero = property((list: LinkedList[String], s: String) =>
{ list.addFirst(s); list.get(0) == s }
)
val getPlusOne = property((list: LinkedList[String], s: String, n: Int) =>
(n >= 0 && n < list.size) ==>
(list.get(n) == { list.addFirst(s); list.get(n + 1) })
)
val thisIsFalse = property((list: LinkedList[String], s: String) =>
{
val listt = list.clone.asInstanceOf[LinkedList[String]]
list.addFirst(s)
listt.addLast(s)
list == listt
}
)
val tests = scala.List(
("addsLengthOne", addsLengthOne),
("getZero", getZero),
("getPlusOne", getPlusOne),
("you're a big fat liar!", thisIsFalse)
)
def main(args: scala.Array[String]) =
tests foreach { case (name, p) => testStatsEx(name, check(p)) }
}And when we run:
$ scala -classpath .:ScalaCheck-1.2.jar CheckLinkedList
+ OK, passed 100 tests.
+ OK, passed 100 tests.
+ OK, passed 100 tests.
! Falsified after 2 passed tests:
> ARG_0 = "[, a, b]"
> ARG_1 = ""
java.lang.Error: you're a big fat liar!: Failed(List(Arg(,[, a, b],0), Arg(,,0)))Our usual three properties pass just fine, but notice that ScalaCheck prints the counter-example to the false property. We can determine that this will never be the empty list since the property holds for the empty list (does it? don’t just take my word for it!). ScalaCheck likely tries the empty list one or two times before it declared to have “Falsified after 2 passed tests” using a non-empty list.
Imagine if ScalaCheck had printed a list of length 20 or 30. If our property was particularly complicated, it would be more difficult to reason about our code and the property to determine why what we stated was false. If the property is also false for a list of length 10, we’d probably want to see that counter-example instead to make debugging easier. Indeed, it would be even easier to have the shortest possible list length that still falsifies what we believed to be correct. This concept is known as shrinking and ScalaCheck certainly provides this ability – occasionally with some assistance from the user for user-defined types – a bit like having to declare your own Arbitrary, you also declare your own shrinking strategy and this is also typically trivial.
In our case, the linked list was not shrunk, since we hadn’t provided a shrinking strategy for linked list (and one is not supplied with ScalaCheck), so the first counter-example was used. In non-demonstration environments, it is encouraged to put this additional effort in to your testing practices by supplying a shrinking strategy for user-defined types (if possible and sensible – it is not always so).
Automated unit testing is an incredibly important tool to any programmer – even when using Java. It serves as rigorous documentation at the very worst and more typically, as a robust unit testing platform (300 unit tests in 25 lines in a demo – it’s usually even better than that! here is over 30,000 unit tests).
Coming up with good properties is an extremely (this adverb cannot be exaggerated) disciplined task and I implore any programmer to strive to do it effectively. Note that stating one property may imply others, so stating those others is potentially redundant. In other words, it is the set of properties that make up the unit for analysis – you cannot necessarily declare the legitimacy of each one independently.
This form of testing is a physical manifestation of an integral part of computer programming – the formation of the logical theorem (see Curry-Howard Isomorphism) that makes up the program. We conclude by noting that this more disciplined, robust and formal approach to programming requires considerably less effort than traditional unit testing techniques, but rigorous mental discipline. It can also be observed that this approach de-emphasises the English description (i.e. function name, javadoc, etc.) as a meaningful method of extrapolating function behaviour.
I was trolled yesterday – I think – I still don’t quite know what “troll” means, since it seems to be a universally applicable verb to describe an action that you dislike. Maybe I wasn’t trolled. I was in the #ocaml programming language channel when a user started displaying an ignorance of the Haskell programming language. I made a small effort to point out that the propositions being put forward were incorrect, but it turns out that “of course I would say that, I am a Haskeller” and so the truth value of the propositions were never explored.
No, I am not a Haskeller. I am not an anti-Java, O’Caml hating, Scala using Haskell worshipper. I completely reject this attempt to assign cult status to the various programming languages. As a matter of fact, I completely reject the existence of the concept of X Programmer for any value of X such that X is an element of the set of all computer programming languages. Correct, Java programmers do not exist. Try telling that to your local recruitment agent.
The corporations are having a field day, while amateurs continue to repeat the many different brand/meme names. “Oh hi, I am a C# Programmer, what religion… err programming language fraternity do you belong to?”. My criticisms of Java do not stem from a personal distaste or apostasy; they stem from the fact that it is indeed, far removed from anything useful, practical or resembling soundness in the practice of computer programming.
Can you imagine two motor mechanics discussing their day jobs where one says, “I am an NGK spark plug installer”, to which the other replies, “oh, I am a Champion spark plug installer, but I use NGK on my own vehicle”? It is this degree of absurdity that I assign to any notion of Java Programmer, Haskeller or what-have-you. It is simply and extremely ridiculous. No really, it is. I won’t pretend otherwise despite any scoffing.
Take for example, the distinction between Java and C#, which is almost zero, in the greater scheme of computer programming language theory. What benefit does distinguishing a “C# Programmer” from a “Java Programmer” give? It serves only to resemble status and cult membership. They are both utterly useless as computer programming languages (yes, this is despite their popularity). Members of both of these cults will scorn at this proposition simply because it appears provocative and causes offence – not because there is evidence to the contrary (there is an enormous amount of evidence supporting the affirmative position, but that’s another topic). What if it is true?
I predict that the many members of the current (why was I born in this era?!) anti-intellectualism establishment probably wouldn’t read this rant to this point, so I’m probably preaching to the choir when I point out that the practice of computer programming is founded on various fields of mathematics.
What does this have to do with the latest advertisement on msdn.com or whatever bullshit marketing material you subscribe to? Nothing. Not a bit. So no, I’m not in your cult, I’m not in cults that rival you, I’m not in a cult that considers itself superior or inferior to yours. I’m an independent thinker.
Your inability to see beyond subscription to cleverly-constructed brand naming is complete bullshit, that’s what it is.
When I encounter pseudo-science, it is usually from the computer programming community perverting the mathematical discourse of computing science or the religious fraternity attempting to keep their logical absurdities propped up. I started reading about some of the amusing wonders of Homeopathy a few years ago and I recently came across this gem – a pure demonstration of utter stupidity and ignorance that will leave you flabbergasted. I don’t think this person is consciously lying, do you? Enjoy :)
P.S. It is Stephen Hawking (no ’s’)
I am constantly checking the version of scala-library.jar and scala-compiler.jar when I am using Scala to verify that I am using the correct version. Here is a lookup table with the MD5 hash for myself and anyone else who does the same:
2.7.0-final
79e45028a358f0deab9e569d3ba4ab70 lib/scala-library.jar
70c0fbd0f1f9b69e6073475ac815fed0 lib/scala-compiler.jar
2.7.0-RC3
9172d38ec2429f195f7c0d33f79f637b lib/scala-library.jar
1531ca6819bc6cb9a22ff468255ed3a5 lib/scala-compiler.jar
2.7.0-RC2
8620b95f78e48f1ff1e84ebff4b3519e lib/scala-library.jar
b4c7815aa711e7d810b8a1098f2952ca lib/scala-compiler.jar
2.7.0-RC1
9284692b287677dc4d6535b0b58beac7 lib/scala-library.jar
52fdbf4c6848e8df235092c7c0d85de0 lib/scala-compiler.jar
2.6.1-final
b0b1f651acc03864d5c9aea8e2e8d37f share/scala/lib/scala-library.jar
c546daad2358da9d00793ee6fa5a727e share/scala/lib/scala-compiler.jar
2.6.0-final
ee5bc8b07c853eaff7ff5570a9a8e402 share/scala/lib/scala-library.jar
6486d3fd03d6223eca8230589372926a share/scala/lib/scala-compiler.jar
2.5.1-final
958b1029fa5c016bb4d8cce61969dce5 share/scala/lib/scala-library.jar
7b078714f2bfda25b2c55adc0ce9ec47 share/scala/lib/scala-compiler.jar
2.5.0-final
a55fdd200521aaec309319c780d0acc3 share/scala/lib/scala-library.jar
d58909b8433137ce452cabe91c56b334 share/scala/lib/scala-compiler.jar* I will never again be put in a position where a client requirement cannot be met in effort proportional to its complexity, as a result of the incompetence and outright malpractice of a fellow self-proclaimed computer programmer.
* I will never again be put in a position where I must tell a client that their requirement is overdue as a result of the consequences implied by the incompetence of a fellow self-proclaimed programmer.
* I will never again be put in a position where I must hack at software in most unsavoury ways (i.e. likely defective; unable to decompose perpetually) in order to achieve a client requirement satisfactorily – this flows from exclusive competence and thus, the elimination of incompetence.
F.F.S., The bar is not that high!
NEVER. EVER. AGAIN.
Religiosity is a neurological disorder
I noticed once before that this site was taken off Google’s search results immediately after posting a number in hexadecimal format that was apparently a copyrighted work and therefore, a violation of some other country’s law – something about DMCA. I immediately retracted this post and the web site returned to Google search results.
So I ask, what have I done now? Why can’t I google up my own rantings? Anyone got any hints?
Raf – a colleague – gave me the following problem:
Given a String (x) containing only characters a-z, write a function (f) that returns a base 10 integer, which converts the String as if it were a base 26 numeral. Function f is bijective.
Here are some example runs:
x | f(x)
empty | 0
a | 1
b | 2
z | 26
aa | 27
az | 52
ba | 53
bz | 78
aaa | 703
aaz | 728
aza | 1353Using your preferred programming language, implement function f.
My solution is in a comment on this page. What is yours?
Scalaz 2.4 has been released and includes some significant updates.
Scalaz API Specification Scalaz Demonstration Code Scalaz Source Scalaz Specification Tests Scalaz Home Page Scalaz Change List
Part 1 of 8
Part 2 of 8
Part 3 of 8
Part 4 of 8
Part 5 of 8
Part 6 of 8
Part 7 of 8
Part 8 of 8
After a heavy weekend of squash, my Magnesium and Zinc depleted body in all its tiredness offers the following universal law of pseudo-scientific claims for analysis:
If someone claims that the concept of Monads (a computation model offered by Category Theory) are for side-effects, then you can be absolutely certain that the person making the claim has absolutely no idea what Monads are for. Not even the slightest. You should consider their credibility on the topic to be absolutely zero.
Comments? Does this count as the ever common Monad Tutorial? :)
Took me a while to recall the right keywords to come up with this excellent interview between a representative of the Canadian Government and Ezra Levant.
There are few things more amusing than listening to a theist coming to terms with the Theory of Evolution. As is often the case, there is either complete ignorance (and if honest, an admission to this extent) or an attempt to unify the fact with the dogma.
But this one is in a category of its own and had me laughing hours afterward:
Referring to this, er typical piece of er, collection of “thoughts” (I’m being nice so as not to distract from the great quote) with emphasis on a quote from this piece.
Referring to Java closures (sigh can we just use Scala yet? please?):
Extra verbosity makes sure that the code guides me along its intended path
Slava Pestov responds in his typically brilliant fashion:
He’s absolutely right. Closures have no place in a low-level procedural language whose target audience consists of programmers unwilling to learn to be productive.
So true Slava, so true.
*Don't do this*
**Do this**conjunction (∧)
if(p) q else false
p && q
p ∧ q
conditional/implication (→)
if(p) q else true !p || q ¬p ∨ q
negation of conditional/implication
if(p) !q else false
p && !q
p ∧ ¬q
negation of conjunction
if(p) !q else true
!p || !q
¬p ∨ ¬q
disjunction (∨)
if(p) true else q p || q p ∨ q
negation of inverse conditional/implication
if(p) false else q !p && q ¬p ∧ q
inverse conditional/implication
if(p) true else !q p || !q p ∨ ¬q
negation of disjunction
if(p) false else !q !p && !q ¬p ∧ ¬q
if(p) true else false p
if(p) false else true !p
Infix (least to highest precedence)
|
^
&
< >
= !
:
+ -
* / %
~Postfix (unary_)
+
-
!
~Operators ending with colon (:) are right-associative.
Many people who are coming in to Scala first encounter the Option type, which may be thought of (among other things) as a type-safe null. They also encounter pattern matching as both a new and (relatively) powerful concept, but also one that is easy to understand. This leads to quite a lot of use of pattern matching and often excessively so in what I have observed.
Particularly with a type as trivial as Option, it is almost always possible to do away with pattern matching by using a higher-order function. Use of this function is typically preferred over pattern matching as tighter code. In fact, it is important to observe that it is possible to encapsulate all forms of pattern matching over Option with one simple higher-order function:
def option[A, X](o: Option[A])(none: => X, some: => A => X): X = ...Then, all functions can be written in terms of this one and needn’t pattern match at all. For example, consider Option.map:
def map[A, B](o: Option[A], f: A => B) =
option(o, None, a => Some(f(a)))In this post, I am going to give some common uses of pattern matching, which many developers might find themselves performing, followed by the use of a function that already exists on Option that encapsulates that given form of pattern matching. If you find yourself using pattern matching in a form not listed below, but feel it could be abstracted, then chances are that such a function exists in the Scalaz extension to scala.Option.
I will use the identifier foo below to denote any particular function, including many functions composed, for example, foo(x) may represent the composition of two functions f and g: f(g(x)). I also use the identifier option to denote any value of the type scala.Option.
I hope this helps :)
flatMap
option match {
case None => None
case Some(x) => foo(x)
}This code is equivalent to:
option.flatMap(foo(_))flatten
option match {
case None => None
case Some(x) => x
}This code is equivalent to:
option.flattenmap
option match {
case None => None
case Some(x) => Some(foo(x))
}This code is equivalent to:
option.map(foo(_))foreach
option match {
case None => {}
case Some(x) => foo(x)
}This code is equivalent to:
option.foreach(foo(_))isDefined
option match {
case None => false
case Some(_) => true
}This code is equivalent to:
option.isDefinedisEmpty
option match {
case None => true
case Some(_) => false
}This code is equivalent to:
option.isEmptyforall
option match {
case None => true
case Some(x) => foo(x)
}This code is equivalent to:
option.forall(foo(_))exists
option match {
case None => false
case Some(x) => foo(x)
}This code is equivalent to:
option.exists(foo(_))orElse
option match {
case None => foo
case Some(x) => Some(x)
}This code is equivalent to:
option.OrElse(foo)getOrElse
option match {
case None => foo
case Some(x) => x
}This code is equivalent to:
option.getOrElse(foo)toList
option match {
case None => Nil
case Some(x) => x :: Nil
}This code is equivalent to:
option.toListcoflatMap1
option match {
case None => None
case Some(_) => Some(foo(option))
}This code is equivalent to:
option.coflatMap(foo(_))duplicate2
option match {
case None => None
case Some(_) => Some(option)
}This code is equivalent to:
option.duplicateI recently ran another Scala training course and I produced a hand-out that seemed to help people understand what a foldLeft is. Here is a brief explanation of it.
Suppose you have the following Java code:
B b = start
for(final A a : listOfA) {
b = method(b, a);
}
return b;You can have any value for start, method and listOfA. Also, method may ignore any of its arguments or even not have them passed at all. You’ll notice that a lot of Java code is written this way, so it would be fair to say that “left folds occur a lot in Java”, despite being encoded as loops.
The above Java code is equivalent to the following Scala code, again for all values of the given identifiers (so long as they type check of course):
listOfA.foldLeft(start)(method)…which is also equivalent to:
(start /: listOfA)(method)…which by the way, is a perfectly sound approach to performing a list reduction, despite what some clowns rubbish on with.
That’s all, hope it helped :)
In my recent post, I made the following introductory statement:
Scala is a far superior language to Java.
Sadly, but most predictably, some people took issue with this fact. It seems I have “stepped on someone’s meme” so-to-speak. Programming languages, unfortunately, have formed cliques who defend their territory with classic religious devotion.
It is certainly not difficult to conceive two programming languages where one is inferior to the other, and so long as neither language has any devoted followers, it is acceptable and makes perfect sense to anyone willing to hear it. I invent a language called Plus and it has one function + and integral literals; I invent another language PlusMinus and it has two functions, + and - and integral literals also. PlusMinus is superior to Plus.
We can traverse the futile path of “Actually, whether PlusMinus is superior to Plus depends on whether - is of any value. The non-existence of the - function in Plus may make it superior under some circumstances”, but I’m hoping, perhaps too optimistically, any objectors can see straight through this misnomer.
It is cases like these where the similarities to the typical religious organisations becomes astounding. I am charged with religiosity, because I am completely atheistic (i.e. null hypothesis) about my meme membership, by those who themselves are more religious than ever! Something about pots, kettles and blackness seems apt here. Furthermore, it is quite often the case that when the charges roll in, in defence of Java, those making the charges know Java quite poorly anyway (most so-called Java programmers do in my observations) – another religious theme that seems to be deeply embedded.
The status of “Java” has been artificially elevated by its groupthink members such that any attack or suggestion of inferiority is reviled, even if the suggestion is perfectly rational and able to be supported with evidence. I could simply discredit their understanding of their belief system by demonstrating how little they know about it (I am always surprised at how easy this is), but it does seem somewhat distasteful. Alternatively, I could present aforementioned evidence, only to have it (predictably so) misunderstood and misrepresented in various forms of logical fallacy.
No, I’d rather work toward abandoning religiosity itself and demonstrating that reason trumps. After all, like most religious memberships, I don’t think these charges have any kind of malicious intent or deceptive techniques behind them, invoke Hanlon’s Razor:
Never attribute to malice that which can be adequately explained by stupidity.
Just for kicks, from http://en.wikipedia.org/wiki/Doomsday_algorithm
sealed trait Day {
def +(n: Int): Day
}
final case object Sunday extends Day {
override def +(n: Int) = n % 7 match {
case 0 => Sunday
case 1 => Monday
case 2 => Tuesday
case 3 => Wednesday
case 4 => Thursday
case 5 => Friday
case 6 => Saturday
}
}
final case object Monday extends Day {
override def +(n: Int) = n % 7 match {
case 6 => Sunday
case 0 => Monday
case 1 => Tuesday
case 2 => Wednesday
case 3 => Thursday
case 4 => Friday
case 5 => Saturday
}
}
final case object Tuesday extends Day {
override def +(n: Int) = n % 7 match {
case 5 => Sunday
case 6 => Monday
case 0 => Tuesday
case 1 => Wednesday
case 2 => Thursday
case 3 => Friday
case 4 => Saturday
}
}
final case object Wednesday extends Day {
override def +(n: Int) = n % 7 match {
case 4 => Sunday
case 5 => Monday
case 6 => Tuesday
case 0 => Wednesday
case 1 => Thursday
case 2 => Friday
case 3 => Saturday
}
}
final case object Thursday extends Day {
override def +(n: Int) = n % 7 match {
case 3 => Sunday
case 4 => Monday
case 5 => Tuesday
case 6 => Wednesday
case 0 => Thursday
case 1 => Friday
case 2 => Saturday
}
}
final case object Friday extends Day {
override def +(n: Int) = n % 7 match {
case 2 => Sunday
case 3 => Monday
case 4 => Tuesday
case 5 => Wednesday
case 6 => Thursday
case 0 => Friday
case 1 => Saturday
}
}
final case object Saturday extends Day {
override def +(n: Int) = n % 7 match {
case 1 => Sunday
case 2 => Monday
case 3 => Tuesday
case 4 => Wednesday
case 5 => Thursday
case 6 => Friday
case 7 => Saturday
}
}
// From http://en.wikipedia.org/wiki/Doomsday_algorithm
object Doomsday {
def anchor(y: Int) = y / 100 % 4 match {
case 0 => Tuesday
case 1 => Sunday
case 2 => Friday
case 3 => Wednesday
}
def doomsday(y: Int) = {
val a = y % 100 / 12
val b = y % 100 % 12
val c = b / 4
val d = a + b + c
anchor(y) + d
}
}scala> import Doomsday._ import Doomsday._
scala> doomsday(1966) res0: Day = Monday
scala> doomsday(2008) res1: Day = Friday
Scala is a far superior language to Java. In fact, of all the languages that I have investigated, it is the most powerful language that also targets the JVM and Java libraries easily (sorry CAL). I have long held the position that there are no (with one corner case) rational justifications for using the Java programming language for anything but educating our children on how not to design a programming language even when targetting legacy code. This has of course, been met with ‘what about this?’ and ‘what about that?’[1] all of which I have been able to refute, except for one niggling corner case.
Client code of existing Java-compiled code would not receive the benefits of generics, since they were erased. For example, if you were to call a Java-compiled method that returned a List<Integer> from Scala, you’d have a reference to java.util.List without the type argument. If you were to call this method from Java, then many methods on the returned List would return Integer in place of the type argument, however, for Scala, you’d have a type AnyRef (an alias for java.lang.Object) just like Java did in the pre-1.5 days. This gave Java one (and only one) case where its use was an improvement over the use of Scala.
This has been the only remaining use case where Scala does not match or exceed Java in ability, however, Martin Odersky (creator of Scala) has revealed that the next version of Scala is to do away with this limitation! Furthermore, we can use the feature today! That is, we can start moving over any Scala <= 2.6.1 code to 2.6.2 right now and have the full advantages of a powerful language and do away with Java forever, unless of course, you’re still out there appeasing the irrationalities of the suits (you poor buggers, no really, I mean it).
From Martin on the Scala mailing list:
Just to confirm:
The nightly build of Scala contains now support for Java generics. The first official release supporting this will be 2.6.2. For instance java.util.List is considered a generic type in Scala in this release. I announce now so that you can experiment with the new feature. Maybe you also already want to start to migrate your codebase to the new scheme.
More precisely, the following things have changed: continues
[1] Here are some that I have met and convincingly (and often quite easily) debunked in conversation. Perhaps I could write about them some time.
* But Java is enterprise-ready
* But Java is a robust language with many libraries
Scalaz is a library written using the Scala Programming Language and tested using ScalaCheck (maintained by myself and Rickard Nilsson) automated specification-based testing. It is released under a BSD open source licence.
Features include:
The Either Algebraic Data Type and general functions over that type
Enhanced Option type
Control package (Functor, Monad, MonadPlus, Foldable, etc.)
Transparent memoisation, loosley inspired by a paper written by Simon Peyton-Jones, Simon Marlow, and Conal Elliott (IFL ’99) titled, “Stretching the storage manager: weak pointers and stable names in Haskell”
Validation package for web form field validation (using Either and monadic functions across it)
Links:
The expected tripe has rolled in after my previous post was publicised on reddit (thanks gst whoever you are ;)).
Here are some of the wonderful accusations:
What a controlling, elitist piece of shit. Worthless article.
Elitist? I’ll accept that and so what? There is nothing wrong with elitism; in fact, I encourage it. Of course, bragging about it publicly is a little distasteful, but that was never the intention. Controlling? I seem to have controlled you, but nobody else. What else can I say? The response is full of gems of insight!
What else did you expect? It is Tony Morris, after all.
Ever heard the term, Ad Hominem fallacy? Such… a critical examination, um, yeah.
…here we have a Haskell zealot…
WTF? I use many languages, one of which is Haskell, but certainly nothing that could be described as ‘zealous’. This seems to be an outright statement of ‘I have tricked myself into describing something other than reality’, since I find absolutely no evidence to support it.
…banned Java from his 6 year-old son’s computer, lest it pollutes his mind. And then he criticises people for being closed-minded!
I concede on this one and should have made my point clear. I have no intention of hiding Java from my son indefinitely. I’m not going to show him a horror film until he a sound moral basis to conduct himself with his peers for the same reason that I will not show him Java until he has a sound basis with which to apply reason and understands the foundations of what it is he is doing (programming).
Well I think we’ve all seen this kind of attitude to some extent, but it all seems to proliferate quite extensively from the ivory towers of academia, i.e. the functional programming community.
They look down on other people who dirty their hands doing “real work” instead of spending time worrying about how pure their language is.
This one is a classic! First, I’d like to dissolve the apparent rift between ‘the functional programmers’ and ‘the imperative programmers’. There simply is no clear distinction and it’s a pointless exercise anyway. Second, I am a member of both communities.
Finally, I’d like you to describe for me what “real work” is. Is it repeating yourself indefinitely because your programming language demands it? No really, I’m asking for a formal definition that we can have a discussion about. You do realise that almost all of Java’s language features started off in “the academic world” (i.e. someone though of a clever idea) and were subsequently perverted before finalising in a JSR (i.e. they were dumbed down to appeal to the masses), right? The results of these JSR teams are merely acts of intellectual fraud. I wish they gave public tours of these circuses so you could see for yourself.
So Tony hangs around mediocre programmers. Big deal.
Perhaps I do, but there is no evidence supporting this position. I have only described quite a small subset of all programmers that I could potentially know of. I think that most people only know one language, but I could be mistaken (from the samples I have anyway). i.e. Java, C#, VB, C, etc. are all the same language under this description. How many people do you know who look to advanced languages for insight?
He only hit the grey mass of average programmers. These used to program in C++ and Visual Basic, and before that in FORTRAN. This grey mass of programmers never have in depth knowledge of the programming language or tools they are using, and are too intelectually lazy to actually learn it. I don’t think java create this kind of guys, but it seems to have the qualities that attracts them.
On a positive note, this response is one that I have not considered enough to my own satisfaction and I thank that respondent for it! ;) Specifically, the response that Java may not create self-delusion, but attracts those who seek it. I’ll have to think about it some more, thanks again.
Thanks for some of the other positive responses that attempt to refute my argument (read: outburst of frustration) with a rational response, it is most appreciated. THINK
Finally, the mainstream media is starting to consider the possibility that Java is not only the crappiest language available on this planet (or at least up there with others such as C#), but also has the capacity for adversely affecting one’s learning capacity.
My 6 year old son is learning computer programming by first understanding the mathematical foundations, then applying what he has learned using Haskell, because it is short and natural (he doesn’t even know what Haskell is). I know many people claim to struggle with this language, but I have always held the position that this is because they are tainted will ill-conceived ideas that are internalised to the point of failing critical examination. My son uses a Linux machine for his work (read: fun), but importantly, Java is and has always been banned on his computer. As his trusted carer, I have a moral obligation to protect him from what could cause possible harm and from my observations, potential self-delusion.
Yes, that’s right. Java appears to me to cause an extreme state of delusion. Too often, I find myself in a conversation with someone who only knows one language (or a few others that are superficially different i.e. strict, imperative, poor type system), but most importantly, they don’t know it that well. I have the unfortunate and shameful scar of knowing Java quite well having worked on the implementation, but it always fascinates me to watch someone argue against what I am telling them even though they are not introducing any new information into the discussion. The conversation often quickly denigrates into chest-beating nonsense by making outlandish claims such as “my having never worked on a large Java application” (so what? and, I’ve worked on the largest Java application on the planet, but again, so what?) and various other forms of logical fallacy. I think we’ve all seen this behaviour to some extent, but it seems to proliferate quite extensively from the bottom of the intellectual pool i.e. the Java community.
It is a logical notion that the most well-versed person on the origins of Christianity is an Atheist (and observations support this), likewise, the most well-versed Java programmer wouldn’t touch such a useless (albeit popular) tool unless under extreme duress. This naturally leads to a conclusion where one attempts to explain the observed irrational behaviour from the Java Junkies who don’t understand the ins and outs of Java that well anyway (seriously, this boggles my mind). I certainly don’t think these people are committing acts of intellectual fraud by trying to deceive me. I am convinced that they have deceived themselves (again, Monotheistic belief systems – such a sound analogy), but to this extent?
The psychology of the human brain continues to fascinate me. The ability for self-delusion is extraordinary. I throw out the hypothesis that Java potentially causes brain damage for examination by anyone who cares. Certainly, I find no other explanation for such irrational behaviour.
Professor Edsger Dijkstra
…who once said the following wise words,
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
Replace BASIC with Java/C# these days.
Finding reason to explain the outward and proactive denial of the evidence that surrounds us by members of religious organisations has always fascinated me. How could an apparently rational person be suffering a sickness of such a magnitude? I have watched Christians deny Evolution without even knowing what it is! I have watched Muslims deny the origin of the Quran. I have wondered what a Christian would say to the charge that the bible is nothing more than a mythological personification of cosmological events and that we still celebrate the birth of the Sun/Son 3 days after its death on the winter solstice (December 22 in the northern hemisphere by the way fellow Australians :)). These questions and many more have fascinated me since I can remember even having independent thoughts as a child.
Aside from those who are not genuine in their delusion for the obvious gains in money and power (i.e. their pawns), I have always been in awe when observing a person suffer such severe delusions with incredible conviction. Having a keen interest in Psychology, I have also wondered if we would ever have a rational explanation for this observation.
Maybe we have found one? As many are now outwardly hypothesising (and others, once did it in silence), religious conviction and psychological disorder are not that unlike.
http://www.sciam.com/print_version.cfm?articleID=434D7C62-E7F2-99DF-37CC9814533B90D7
Of course, this does not detract from the sheer awe.
http://www.news.com.au/couriermail/story/0,23739,22427799-5007200,00.html
PHILIP Lamattina’s spectacular effort at Willowbank near Ipswich on Saturday night has already assumed legend status among Australia’s drag racing fraternity.
He miraculously escaped unscathed from the 500km/h smash that destroyed his $250,000 Top Fuel dragster.
The publisher(s) of this story oughtta be ashamed of themselves. Everyone knows (note: I am exempt from accusations of argumentum ad populum fallacies because I am (and circular reasoning too, got it?)) that SPEED KILLS! Here these journalists are implicitly refuting the known established perversion… er… correction, of the laws of Physics and our understanding of space and time! This is nothing short of failure of reason and I now expect deaths on our roads to increase substantially. All because of some irresponsible journalist(s)!
Actually, I take it back. You see, it was a miracle. Yes, notice the use of the adverb, ‘miraculous’ in the second paragraph. Instead of contradicting our government’s established scientimplistic (yes, I made that up :)) understanding, the article exonerates itself by attributing the whole affair to a miracle. This is permitted under the laws of illogic, which any person is free to invent for themselves, right? Of course.
So you see, that makes sense now. Phew!
On page 85 of Scala By Example, the last paragraph states the following in reference to generalising sequence (aka for) comprehensions:
It would be attractive to enforce these types statically in the Scala compiler, for instance by requiring that any type supporting for-comprehensions implements a standard trait with these methods 1 . The problem is that such a standard trait would have to abstract over the identity of the class C, for instance by taking C as a type parameter. Note that this parameter would be a type constructor, which gets applied to several different types in the signatures of methods map and flatMap. Unfortunately, the Scala type system is too weak to express this construct, since it can handle only type parameters which are fully applied types.
This type system feature being described is called higher-kinded types. Sadly, none of the mainstream, statically-typed languages offer this feature, which leads to enormous amounts of repetition.
In fact, many of the arguments in favour of dynamic languages that I have seen, are refuted simply with the introduction of this very key, but relatively simple (to other type system features) feature. In other words, I only have to batter an eyelid before I have refuted those arguments, which brings me great suspicion of any underlying plausibility. Perhaps there are other arguments that are more plausible, but I have yet to hear any. I digress…
Higher-kinded types would be available in Java/C# if you could write something like this:
static <C<_>, A, B> C<B> map(Convert<A, B> c, C<A> container) {
...Again, sadly, you cannot. But in Scala you can! In other words, the paragraph quoted above is, at least from how I interpret it, false. However, do understand that at the time the paragraph was written, it may have been true (I can neither confirm nor deny this), but my reckoning is that this piece of documentation needs updating at the least.
Without further ado, I introduce the my refutation:
trait Functor[f[_], a] {
def map[b](f: a => b)(ft: => f[a]): f[b]
}
trait Monad[m[_], a] {
def flatMap[b](ma: => m[a])(f: a => m[b]): m[b]
}
trait Filter[c[_], a] {
def filter(f: a => Boolean)(c: => c[a]): c[a]
}My assertion now, is that a Scala sequence comprehension could indeed be written to be type-safe if it only accepted types that adhered to the above interfaces. Am I wrong and if so, what have I misunderstood?
Here are some example (incomplete) implementations of foreach:
object Comprehension {
type Comprehension[c[_], a] = Functor[c[a], a] with Monad[c[a], a] with Filter[c[a], a]
def foreach[c[_], a](c: c[a], e: a => Unit, p: a => Boolean)(implicit ca: Comprehension[c[a], a]): Unit = ca.map(a => if(p(a)) e(a))(c)
def foreach[c[_], a](c: c[a], e: a => Unit)(implicit ca: Comprehension[c[a], a]): Unit = foreach[c[a], a](c, e, (a: a) => true)
def foreach[c[_], a, b](c: c[a], f: a => b, p: a => Boolean)(implicit ca: Comprehension[c[a], a]): c[b] = ca.map(a => f(a))(ca.filter(p)(c))
def foreach[c[_], a, b](c: c[a], f: a => b)(implicit ca: Comprehension[c[a], a]): c[b] = ca.map(a => f(a))(c)
}I await an explanation for what I think is the unwarranted undermining of Scala’s value by Scala’s own documentation!
Kathy Griffin goes from being annoying at worst to an international hero overnight!
a lot of people come up here and thank Jesus for this award. I want you to know that no one had less to do with this award than Jesus.
Kathy, you have redeemed yourself of any debt that you may have owed the community. I take my hat off to you for your courage. Well done.
On a lighter and hilarious note, check this comment out:
The comedian’s remarks were condemned Monday by Catholic League President Bill Donohue, who called them a “vulgar, in-your-face brand of hate speech.”
OK, you can stop laughing at the irony now, STOP! :)
Lazy evaluation is a core topic in computer programming that is also widely misunderstood and often, erroneously trivialised. Here, I will attempt to demonstrate some of the attributes of many common mainstream programming languages; namely strict programming languages. I will also attempt to distinguish intrinsically strict languages from optionally lazy languages by focusing on what intrinsically strict means. As a note, strict evaluation (or strictness) is what lazy evaluation (or laziness) is not.
Some languages are optionally lazy, including one that I use quite a lot in my work called Scala. This means I have the option of laziness, however, the default in all cases is strictness. I have to explicitly annotate laziness (=> in Scala). Some languages are optionally strict; one that I use a lot is Haskell. Laziness is the default, while strictness is explicitly annotated (seq or ! in Haskell). There are many debates about which is the correct default, but whatever the outcome of such a debate, the issue I describe next is one that demands much more attention.
Some languages are forcibly strict. It is these languages that I intend to focus on for the remainder of this post. I assume that my reader either understands or is at least open to just how debilitating a language is that does not support user-defined lazy evaluation in any form whatsoever. I will explicitly discuss the Java programming language, though what I describe is equally applicable to C, C# and many other languages.
In Java, the only lazy constructs are:
if/else
while
for
? : (ternary operator)
&&
||
This is extremely limiting. To make the case clear, I will focus on a particular example of this. Consider the && function of type (Boolean x Boolean) -> Boolean. Here is a profound assertion:
It is impossible to write && in Java yourself.
Some of you might be quick to rebut:
// Sure I can! boolean and(boolean b, boolean c) { return b && c; }
This is a very crucial mistake as you will soon see.
Since the domain of the && function is so small, there is room enough to enumerate it below:
a b a && b
t t t
t f f
f t f
f f f
t ⊥ ⊥
⊥ t ⊥
f ⊥ f
⊥ f ⊥Wait just a minute!! What are those last 4 entries in the table and just WTF is that upside-down T doing!? That upside-down T represents what is called the bottom element, sometimes also written as | when only ASCII is available. It is an extremely important part of the && function (and all functions in fact!). In Java, the bottom element is typically represented by throwing an exception (or sometimes, with null).
Remember, two functions are equivalent if for every element of the domain, the result of function application to that element on either function is equivalent. Here is a more formal definition for function equivalence:
Two functions, f and g, are equivalent if the following property holds:
∀ x. f x ⇔ g x
We could rewrite the + function for int as follows:
int sum(int a, int b) {
return a + b;
}I won’t list out the table for each element in the domain of +, since it is so long, so you’ll either have to do it yourself, or take my word for it that the sum function above is equivalent to + :)
However, why can’t we rewrite &&? If we look at the table for && above and select the penultimate entry, we note the following:
false && ⊥ == false
It is this entry that disallows us from rewriting &&. Look at the following function:
boolean bottom() {
throw new Error();
}What is the result of false && bottom()? It is false of course! This is because && is lazy in its second argument (sometimes; specifically, when the first argument is false). This is impossible to emulate in your own Java function. If we take the earlier function that attempted (but failed) to rewrite && and call:
and(false, bottom())
The result of this function is ⊥ and not false, like it is with &&. Therefore, this function is not equivalent to &&. Further, I restate that it is not possible to write such a function in these languages. Unlike +. which is strict in both of its arguments, && is not and this makes it impossible to write a user-defined version of && and therefore, ||, if/else and ?: and importantly, many other potential functions that many Java programmers are probably not even aware of (Dynamic Programming Algorithms anyone?).
If you are ever forced to use these severely limited programming languages, you could be thankful that you have some primitive lazy constructs for doing very primitive operations (oppression), or you could be resentful for not having the expressive power of other, lazy languages (resistance against oppression) :)
Below is a session with my Scala interpreter to demonstrate that it is indeed possible to write && in Scala (lazyAnd), but not Java. Note that the functions (def declarations) and final variables (val declarations) below are Java functions and final variables all running in a JVM (invoked by the Scala interpreter):
scala> val x = false && error("bottom")
x: Boolean = false
scala> def and(a: Boolean, b: Boolean) = a && b
and: (Boolean,Boolean)Boolean
scala> val y = and(false, error("bottom"))
java.lang.Error: bottom
scala> def lazyAnd(a: Boolean, b: => Boolean) = a && b // can't do this in Java, C#, C, etc.
lazyAnd: (Boolean,=> Boolean)Boolean
scala> val z = lazyAnd(false, error("bottom"))
z: Boolean = falseI am just keeping note of a great talk given by one of the most important people alive today on issues relating to the future of humanity, Sam Harris.
Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Part 7
There are a lot of things that, upon initial investigation, turn out to be false after some deeper analysis. There are a striking number of these propositions that not not only turn out to be false, but it is the inverse that turns out to be true!
One of these is many common descriptions of pure functional programming against imperative programming. Here are some that I have seen:
* functional programming is on the other side of the fence of (or some such) imperative programming. That is, there are two (or more) very distinct, non-unifiable methods or disciplines of programming.
* Functional programming is more restrictive than imperative programming.
I hope to address the first point another time and on the second point, for now, I will assert that:
Not only is functional programming not more restrictive than imperative programming, but quite the opposite is true! Imperative programming is one specific type of functional programming that is relatively seldom worth using.
In the relatively rare (though inevitable) case of performing I/O, only then will I resort to the imperative programming technique within pure functional programming. I will reason about my imperative code as if it were pure anyway, but I also understand that there are many destructive updates that must be appealed to – for example, the many common file system types that are used.
I don’t wish to elaborate on this statement right now, since I am still deciding how I will do it and I also know how this fact can fail to be recognised by many so I want to get it right. Importantly, it sets (one of) a premise for another issue that I’d like to write about some time.
In the meantime, I want to refer to Part 2 of Simon Peyton-Jones’, “A Taste of Haskell”where he says at 1:06:42:
[Referring to the IO data type] This is imperative programming, embedded within Haskell [pure functional programming].
There it is, right there, in one sentence ;)
It is Saturday night and I get to sit at home and read a book by one my favourite authors, Sam Harris. Half my family are currently suffering from influenza, so I’m bound to the house tonight.
I thought I’d take a peek at a news website and I notice that Gwen Stefani is not permitted to wear “revealing costumes” when she performs in Malaysia because of a protest by a “Muslim student group”. Apart from all the usual absurdities of theistic dogma (and particularly, Islamic and Judæo-Christian dogma), this quote cracked me up in laughter:
She [Stefani] will abide by the Malaysian authorities’ guidelines to ensure that her show will not be offensive to local sensibilities.
The funny part, from my humble perspective, is the use of the word “sensibility”.
Watching a religious establishment manipulate its victims with such absurd and utterly transparent, blatant abuse of language usually causes me the most extreme alarm (because of the consequences to humanity), but on this night, after a couple of lonesome wines, I thought I’d take a laugh at just how sick and sad this world truly is. Sensibility!! Can you believe that!? You poor, sick bastards. Yes you, who has been robbed of the ability to think, yeah YOU.
Cheers :)
I recently watched Simon Peyton-Jones’ presentation as OSCON 2007 titled, “A Taste of Haskell”. As usual for Simon, his enthusiastic and very animated presentation was of high quality in both content and the way that content was presented. If you have a spare 3 hours (a little over in fact) and you are interested in learning the basics of a very powerful programming language called Haskell, I recommend that you invest the time in this presentation, which is split into Part 1 and Part 2. Be sure to keep the slides available as well, since a lot of the time, the camera is focused on Simon and not on the slide that he is discussing.
During the presentation, the audience were asking questions of Simon as he was presenting Algebraic Data Types (ADTs), which are written in Haskell using the data keyword. As Simon pointed out, ADTs are a fundamental part of writing Haskell. I felt that members of the audience were perhaps considering the concept of an ADT to be more complicated than what it really is. It truly is quite simple and in this post, I hope to try a new tact to explain this very simple concept. As Simon also pointed out, ADTs are important, powerful and fundamental to programming, but I don’t expect this to be obvious at first. First, let’s understand exactly what an ADT is. If the following confuses you and you prefer Simon’s (or some other) approach, then please ignore it. I intend to use a (probably) familiar language to demonstrate what an ADT is.
In Haskell, ADTs are closed. That is, at the point of declaration you specify all the constructors of the ADT and it is not possible to dynamically add more constructors for that type. For example, the Haskell Maybe data type is written as follows:
data Maybe a = Just a | NothingTherefore, the Maybe data type has 2 and only 2 constructors. It is the “and only 2” that makes this data type a closed algebraic data type.
If we consider a Java or C# class that can somehow enforce 2 and only 2 subclasses, then we could emulate closed algebraic data types in these languages. Indeed, it is possible to do so, however, you have to get really quirky with the language at hand. I have written about this before, but instead of using this trick, I am going to invent a new keyword for these languages called klass.
A klass declaration is always abstract and all of its subtypes are always specified in the same source file and they are always implicitly final. An attempt to subclass a klass outside of its own source file or any subtypes of a klass is a compile-time error. Furthermore a klass cannot declare anything at all in its body – it simply takes on the default constructor and nothing more is permitted.
Given this new keyword, we can write the Haskell Maybe data type as follows:
class Maybe<A> {
}
class Just<A> extends Maybe<A> {
final A a;
Just(A a) {
this.a = a;
}
}
class Nothing<A> extends Maybe<A> {
}To reiterate, no other classes may subclass Maybe, Just or Nothing and there is a single type parameter that I have called A (and Haskell calls a by enforced convention). Therefore, if a function or method is passed an instance of Maybe<A>, we can be certain that it is either a Nothing<A> or a Just<A> and in the Just case, we might wish to access that A (which is a field called a).
Indeed, we might write code that is similar to the following:
X someFunction(Maybe<A> m) {
if(m instanceof Just) {
Just<A> j = (Just<A>)m;
foo(j.a);
// this definitely holds, but see description below
} else if(m instanceof Nothing) {
bar();
}
}This code is effectively pattern matching (another topic that Simon talked about and the audience seemed unnecessarily confused). In the second if statement I have ensured non-overlapping pattern matching, which is a good practice that I follow. That is to say, the order of my if statements is not relevant to the outcome of the function. You might recall that Simon said that pattern matching occurs “top to bottom”, however, I prefer not to rely on this by not overlapping patterns. If I’d left out the second if condition as a simple else block, then I have effectively said, “and everything else” and the behaviour of the function would not change. However, this pattern overlaps with the Just case and the behaviour of the function would be affected if I swapped their order. This notion of “and everything else” is denoted in Haskell pattern matching with an underscore or sometimes, a variable to bind to.
The code above, written using Haskell pattern matching would look like this:
someFunction :: Maybe a -> X -- remember, this is a type declaration
someFunction (Just a) = foo(a)
someFunction Nothing = barSimon talked about pattern matching as “decomposing” a data type. You can see in the earlier code that I have pulled apart the Maybe into its components of Just or Nothing and I have “decomposed” the components of the Just further, by getting the A out of it. This is what Simon was referring to when he was talking about decomposition of a data type using its constructors.
Of course, in Haskell, you can create all sorts of data types and the Maybe data type is very common. There is another called Either that looks like this:
data Either a b = Left a | Right bIt is almost like Maybe except that both constructor cases take an argument of any type.
Here’s the fun part :) If we take a look at all the excitement with “non-nullable types” using the type system in Java and C#, then we see that this is exactly what the Maybe data type does in Haskell, also using the type system. In fact, imagine “exceptionable types” in these languages, where returning one of these “non-exceptionable” types from a method cannot throw an exception. This is exactly what the Either data type above does also using the type system, since we can return “either the value to be returned or the exception that was thrown”. Furthermore, the Maybe and Either data types are one line of Haskell code and just 2 of many possible data types. In other words, and as is usual for previous industry trends, the excitement around Java/C# non-nullable types, is just a fundamental library feature of Haskell that has been there for years. How about that eh? :)
The next time a Haskeller just smiles and nods at a Jumping Java Joey or Shaggin’ C Sharpy who is all excited about non-nullable types (or any “revolutionary” language feature in fact), you’ll now know why since both Maybe and Either are so trivial and fundamental, that they are included in the default import of the Haskell standard library (like java.lang.*).
I hope you too can smile and nod after reading this post and understand Algebraic Data Types (and Pattern Matching) :)
I came across a thread today on javalobby. Actually, I was referred by Ricky Clarkson who seems to challenge the Java Religious Establishment with seemingly greater patience than I could possibly exercise. Here is a link to the thread.
I have long postulated that programming in general and Java particularly, exhibits some strikingly similar attributes of religious establishments. I have discussed this hypothesis with a few people and we have even come up with the idea of finding a correlation between preferred programming language and religious conviction. Of course, this was all discussion and no “doing”, but it’s an interesting discussion nevertheless. We even entertain conjectures about what we believe the outcome to be. Mostly, correlating religious ideologies that are founded on the most powerful delusions and programming languages that are also founded on extreme delusion and then extrapolating along less mature religions with more transparent delusionary characteristics.
Many people point to some of the absurdities that come out of religious establishments for humiliation, because they are well, quite blatantly in violation of sound logical reasoning. As a side note, I often observe this violation being resolved by resorting to Fideism – a symptom of the religion sickness that I hope to write about soon. I actually empathise with the people who have been manipulated into such extreme delusions. I do not encourage human suffering and I do whatever I can in terms of self-discipline to ensure that I do not denigrate to the perverted practice of esteem boosts by pointing at the weaknesses of others – mostly, because I hope and expect the same from others (I am a moral Altruist).
I encourage you to do so as well as you read the following quotes from the aforementioned thread:
Other languages have lots of problems that java just doesn’t have.
Most language concurrency models are inferior to Java’s.
Most languages don’t have as good functional programming as Java.
Java’s type system is precise and predictable, more so than many languages.
Notice how this person is convinced that these statements are true. There is no act of conscious intellectual fraud here. Ask yourself why? How on earth could someone have been led into believing such absurdities? My point is for example, there are some very plausible explanations and methods of counselling for believers in the Judæo-Christian delusion; can we use these lessons to describe the behaviour of the person quoted above, and therefore, offer counsel to this person, who is also suffering delusions? Is the approach that Ricky Clarkson is taking – assumingly to heighten the awareness of the audience of his words – a sound one? Can we make predictions about its outcome?
The infamous Robert M. Pirsig (Zen and the Art of Motorcycle Maintenance) quote seems apt:
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion, it is called Religion.
C, Java, C# et. al. (imperative with poor type systems) languages are low level languages. Many people are not aware of this fact, especially those who are only aware of languages that are imperative with poor type systems. This behaviour is probably best described by Psychologists than I will attempt, so I will not attempt any explanations for it.
I refer to pages 58-61 of Types and Programming Languages (0-262-16209-1) on the chapter about the untyped lambda calculus where author Benjamin Pierce notes that the the value false for the Church Boolean encoding is the same as the value zero for the Church Numeral encoding.
λt. λf. f λs. λz. z
Pierce then goes on to note that:
Similar “puns” are common in assembly languages, where the same pattern of bits may represent many different values – an int, a float, an address, four characters, etc. – depending on how it is interpreted, and in low-level languages such as C [emphasis mine], which also identifies
0andfalse.
I wonder if the aforementioned programmers – those aware of only low-level languages, therefore call languages of “the highest level that I am aware of”, high-level languages – are willing to claim that Pierce has made a grave mistake, or if it will invoke the possibility that maybe there are more levels out there.
If, for just one person, it is the latter, then the objective of this post has been achieved ;)
From http://cafe.elharo.com/java/internal-and-external-exceptions/
Perhaps the continuing confusion over the difference between checked and runtime exceptions in Java is because we haven’t named them properly.
Yippeee! About time a Jumping Java Joey took notice of that fact that language has an enormous power to influence if you are incapable of independent thought.
…I think we should should start calling checked exceptions “external exceptions” and runtime exceptions “internal exceptions”.
Ugh.
How about type error? bottom? Or undefined partial function? Or ⊥
As abruptly as there was hope, that same hope was ripped away.
I am absolutely surprised at the number of failed examples of inheritance. What troubles me is the extent of ignorance prevailing on the subject of inheritance. Every once in a while, I read an old rant by a Blub programmer making claims to an understanding of a topic while simultaneously proclaiming that there are so many others without this understanding. Less often, I am compelled to write something myself.
I will start by using Blub grammar and syntax, but try to keep the usual euphemisms and loaded words to a minimum (I have two, annotated with warnings).
Look at the following interface declarations:
interface I {
T i();
}
interface J {
U j();
}
interface K extends I, J {}If a method accepts a type K, what that method really means is that it accepts a type that is composed of both type I and J, which is more general than type K. I am ignoring the fact that interface K may have some additional restrictions that are not enforced by the type system, because well, this is Blub after all and using type systems to denote formal requirement specifications is well beyond Blub. If you have a type L that is composed of I and J, you will not be able to pass it to the method. Instead, you need to write an “Adapter” (WARNING: euphemism) from L to K.
I now propose a hypothetical language (still Blub though) that allows you to pass a “I with J”, which means it might be a K or it might be some other composition of I and J. Note that a compiler can not deduce that K is composed of I and J and generalise this type, since this requires the compiler to compile I, J, K and all compositions of I and J, which is potentially infinite. In other words, time goes this way —>, not that way <–, despite what the Blub type systems say.
In my hypothetical language, you do not explicitly give method arguments types. Instead, if you call both i() and j() within the aforementioned method, the compiler or type inferencer will determine that the method argument has type I with J. Surely, you have seen software in Blub languages, where you pass a type with a bazillion methods and only one or two of those methods are used when it is passed? It’s a problem, right? Ever used one of those “mock frameworks”? (WARNING: euphemism for “workaround”). Have you ever passed a K and only called i()?
In my hypothetical language, if you only call i(), then the method argument type will be inferred to I, not K, not even I with J, since remember, we do not explicitly annotate types on method arguments.
Now, is my hypothetical language really hypothetical? No! You see, there are (at least) not-so-crap type systems out there that permit this level of flexibility. They are far more powerful than this little rant purports, but you’ll just have to take my word for that. What I have effectively described is (one aspect of) Type Classes from a language called Haskell, which can also be used in Scala and other languages with at-least-reasonable type systems.
In other words, inheritance dunrite is as easy as putting down those languages that have got it all wrong and stop pretending that they are sensible or “industry grade”. Stop trying to understand their inherent contradictions through cognitive dissonance, write books about the nonsense, invent design patterns, refactorings, workarounds and mock this and that and framework foo and blah blah blah (can I breath now?). Furthermore, standing on a pedestal and proclaiming that “I know something that you don’t so na na!” is really quite silly, even if it is true (which it isn’t more often than not as has been seen!).
There is much more to inheritance than even the most expert Blub programmer can possibly imagine. I have only just touched the surface by introducing type classes here.
Most people prefer to believe that their leaders are just and fair, even in the face of evidence to the contrary, because once a citizen acknowledges that the government under which he lives is lying and corrupt, the citizen has to choose what he or she will do about it. To take action in the face of corrupt government entails risks of harm to life and loved ones. To choose to do nothing is to surrender one’s self-image of standing for principles. Most people do not have the courage to face that choice. Hence, most propaganda is not designed to fool the critical thinker but only to give moral cowards an excuse not to think at all.
– Michael Rivero
There is a lot of misunderstanding about the difference between idempotence and referential transparency. My plan here, is to explain the key differences without going into any specific detail about either concept. I plan to write something about referential transparency in the future and when I do, I will refer here to dispel any myths regarding idempotence.
I will assume that my reader is roughly familiar with the concept of referential transparency, but not necessarily its implications (since there are many), even though some clearly demonstrate a lack of understanding of this concept, strangely accusing others of same (go figure?) and even trying to proclaim that Java has higher-kinds while suggesting that others do not understand Java’s (mediocre) type system. Ignorance is bliss and all that, anyway on with the story…
Here is a fact; all idempotent functions are also referentially transparent, but not necessarily the other way around. Let us express this fact by other means; a referentially transparent function is not necessarily idempotent, because it is (only) possibly idempotent.
Idempotence can be easily written as follows. A function (f) is idempotent if the following property holds:
f o f = f
That’s all there is to it. Since many of my audience are Java programmers, I will appeal to their potential misunderstanding here and elaborate. The o symbol means function composition. The statement can be read as “the function f composed with the function f is equivalent to (just) f”.
Function composition comes about by… well composing functions. Suppose a function (f) that accepts a type Y and returns a type Z and another function (g) that accepts a type X and a type Y that returns another function that accepts a type X and returns a type Z. We express this as f o g.
Here is an example in the favourite programming language of some:
class Foo {
static String f(int i) {
return Integer.toString(i);
}
static int g(char c) {
return c + 7;
}
static String composeFG(char c) {
return f(g(c));
}
}Easy Peasey right? In my statement above, the type X is char, Y is int and Z is String. Function composition is written in Java as f(g(a)). Back to the definition of idempotence, which states (in Java syntax), that f(f(a)) is equivalent to f(a). Clearly we see that f must at least have the same type in its argument and return type in order to satisfy idempotence. This means that our previous example has no idempotent functions, however, they were all referentially transparent. Furthermore, a function that is referentially transparent and having the same type in its argument and return type is not necessarily idempotent. A counter-example is easily produced:
class Bar {
static int add1(int i) {
return i + 1;
}
}Since there exists at least one (in fact, all in this case) arg for add1(add1(arg)) such that it is not equivalent to add1(arg), then add1 is not idempotent. For example, add1(add1(7)) is not equivalent to add1(7), clearly.
Here are some insights. Adhering with my naming convention, suppose the function add0. Guess what? It is idempotent. Also, multiply1 is idempotent. Every single function on this web page is referentially transparent, but only the two aforementioned hypothetical functions are idempotent.
We might write this using logic as follows for add0
∀ n | n ∈ Z. n + 0 = n
For all n such that n is an element of the set of integers, n + 0 = n [is a true statement].
…and for multiply1
∀ n | n ∈ Z. n * 1 = n
For all n such that n is an element of the set of integers, n * 1 = n [is a true statement].
For completeness, here is an actual idempotent function with the added twist of a polymorphic type parameter (generic parameter in Java speak):
class Baz {
static <t> T identity(T t) {
return t;
}
}I hope this clears some things up :)
Dear Prime Minister John Howard of Australia, Many of my readers may not be aware that all people over the age of 18 are required to vote in elections by law in Australia. The exceptions are (of course) the organisations with an artificially heightened religious status such as Jehovah’s Witnesses.
I was de-listed to vote years ago and when I contacted your Australian Electoral Commission (AEC) to apply for conscientious objector status, I was told I needed to belong to a religious cult in order to be eligible and that I am not permitted to think for myself under Australian law. I resented this implication and I have since not ever enrolled to vote. Nevertheless, the AEC operator told me that to be a conscientious objector and at the same time, exist independently of a religious cult/organisation, that I simply should not enrol to vote – to break the law – go figure? I hadn’t voted before this time, since I had always submitted an empty voting ballot form. I won’t bore you with my somewhat complicated reasons why (relative to your comprehension skills that is).
But this is not the reason I write to you. No, it is the very rare victory that Science has had recently. I am writing to you to make a deal. I will forgive the implication that Australians are not permitted to think for themselves if you follow the lead of the UK government and even more, I will submit one vote for you! I will even forgive you for taking away my firearm licence those many years ago just because some psycho 2500km away went berzerk with a semi-automatic rifle. I know you do not possess critical thinking skills Mr. Howard, and neither do your nemeses, but I will forgive you for that.
You see, the UK government have recently announced that Intelligent Design has no part in a school that teaches Science; how great is that for our society!? This announcement has tipped me over the edge and given me some hope – I will do just about anything to have the same for our vulnerable Australian children. Please Mr. Howard!
So, I implore you, please follow suit, for the sake of my children and their well-being if anything. But of course, I know all you care about at the end of the day is my vote and believe me, you will get it! I will even vote for a government; that’s how desperate I am to save my children from the Monotheistic attacks that are conducted so readily and openly in so many civilisations today, including the one that you currently govern.
So, how about it?
If you receive this message from Mercurial when trying to do a hg push, ensure that the web server has write permissions to the repository. Had me stumped for a while ;)
abort: ‘http://foo/bar’ does not appear to be an hg repository!
A core part of Haskell’s type system is that of type-classes. If you have never used type-classes, then there is a pretty good description in Yet Another Haskell Tutorial (YAHT). Haskell type-classes have been likened to Java/C# interfaces or Scala traits, but there are some significant differences.
With Scala’s implicit definitions (defs), it is possible to come pretty close to emulating Haskell’s type-classes. This ability can make writing certain constructs very simple and also, extremely flexible. Imagine you were asked to write a function that found the maximum value in a List of values. In Scala, we might write it like this:
object O {
def maximum(x: List[Int]): Int = x match {
case Nil => error("maximum undefined for empty list")
case x :: y :: ys => maximum((if(x > y) x else y) :: ys)
case x :: _ => x
}
}Notice that if we wish to write the function for some other type besides Int, we would have to start again. Or, we could generalise to the Scala Ordered type:
object O {
def maximum[a <: Ordered[a]](x: List[a]): a = x match {
case Nil => error("maximum undefined for empty list")
case x :: y :: ys => maximum((if(x > y) x else y) :: ys)
case x :: _ => x
}
}So we accept now that we can find the maximum of any type, so long as that type implements the Ordered trait/interface. But what if we have a type that doesn’t implement that interface? Worse still, what if our type does implement that interface, but we wish to redefine ordering? The only solution here is to create a new type that wraps the old type and redefines ordering. In Haskell, this is called “newtyping”, because it is done with the newtype keyword and is one line of very trivial code (newtype T = T U) plus the two or three for the redefinition of ordering. However, in other languages, this is a little cumbersome and can lead to the bloating of code that is difficult to understand.
Scala implicit defs come to the rescue here. But first, a little introduction to two core Haskell type-classes called Eq and Ord. Here is an excerpt of their definitions:
class Eq a where
(==), (/=) :: a -> a -> Bool
-- omitted as superfluous to the topic
class (Eq a) => Ord a where
compare :: a -> a -> Ordering
-- omitted as superfluous to the topicThis first declaration is of the Eq type-class and states that to implement the class over an unbound type (a), one must define equality such that gives two instances of (a), return a boolean value indicating equality (or non-equality). The second declaration is of the Ord type-class and states that to implement the class over a type (a) that is bound by the type-class Eq, one must define ordering such that given two instances of (a), return a type Ordering (which has only three possible values; LT, EQ, GT).
We can express something similar in Scala. However, note that the type parameter (a) is not co-variant, while all Haskell type parameters are co-variant. This is because Haskell is a pure functional programming language, while Scala is not.
trait Eq[a] {
def eq(a1: a)(a2: a): Boolean
}
trait Ord[a] extends Eq[a] {
override def eq(a1: a)(a2: a) = compare(a1)(a2) == EQ
def compare(a1: a)(a2: a): Ordering
}
// for completeness
sealed abstract class Ordering
final case object LT extends Ordering
final case object EQ extends Ordering
final case object GT extends OrderingNow comes the interesting part (sorry to the impatient :)). Imagine now that we could write our maximum function, where we could say “the maximum of a list of any type (a) such that there exists one and only one implementation of the Ord trait for type (a) implicitly defined in compiler scope”. That is to say, if there exists two or more implementations of Ord, fail the compiler with an ambiguity error (indeed, many Scala newcomers have likely observed these ambiguity errors from the core Scala APIs). If there is no implementation within scope, fail as well.
Here is how we would write the function now:
object Maximum {
def maximum[a](as: List[a])(implicit o: Ord[a]): a = as match {
case Nil => error("maximum undefined for empty list")
case x :: y :: ys => maximum((o.compare(x)(y) match {
case GT => x
case _ => y
}) :: ys)
case x :: _ => x
}
}Notice that the function takes two arguments, however, one of them is declared implicit. This means that we do not need to explicitly provide this argument (though we can and we might to resolve an ambiguity, but there are also other means). So long as there exists one implementation of Ord[a] implicitly defined in compiler scope, then this implementation is used.
Let us write such an implementation:
object Ord {
implicit def intOrd = new Ord[Int] {
def compare(a1: Int)(a2: Int) = if(a1 == a2) EQ else if(a1 < a2) LT else GT
}
}Notice that the definition of intOrd is declared with the implicit keyword. Now, if the intOrd function is in scope (and no other implementation is), then we can call the maximum function with a list of integers. Indeed, if we had some other definition of ordering for integers (which is rarely the case for integers, but imagine it were some other type), we would not have to rewrite anything to continue using our maximum function.
Also, be aware that implicit definitions are not transitive. This means that although we might have an implicit definition from Int to Ord[Int] and we might have some other implicit definition from T to Int, however, this does not imply that we have an implicit definition from T to Ord[Int]. This attribute is very unfortunate and quite limiting of the potential of implicit definitions, but one that is to be accepted nonetheless.
At this point, some would be thinking, “so what?”. After all, some have no problem with newtyping (or adapting or design patterning or whatever you want to call it). However, I draw your attention to one example of many where this approach would save much more work. Let us take a look at that List.range function. Notice how the range function is defined over integers only? If I wanted to get a range for some other type, I’d have to rewrite the range function, or I’d have to write a conversion to type Int and use that. Both very annoying.
Indeed, the range function can be generalised to any type that has the notion of a successor (as well, a predecessor if we wish to support backward ranges). However, if we were to define a range function with a step n (default: n = 1), then invoking our successor or predecessor function n times may lead to an inefficiency that is resolved by the integer type, because it has the constant-time + function. Indeed, we would need another function successor(n) so that this efficiency gain could be utilised for types that support it, such as the integer type, where it would use the + function. By default, this implementation would simply invoke the successor function n times. We will acknowledged this fact but will ignore it hereon.
Let us define our successor function:
trait Successor[a] {
def succ(a: a): Option[a]
// for efficiency reasons, we might define this function
// A default implementation invokes the succ function n times.
// The integer implementation would override and use +
// def succn(n: Int)(a: a): Option[a]
}The succ function returns a succeeding value of type (a) if it exists, but no value if there is no successor i.e. the type is maximally bounded. This is the case for the integer type where Integer.MAX_VALUE has no successor. We would write the implementation like so:
object Successor {
implicit def intSuccessor = new Successor[Int] {
override def succ(a: Int) = a match {
case Integer.MAX_VALUE => None
case _ => Some(a + 1)
}
}
}Now, we can write our range function such that it is defined over any type, so long as that type has one and only one implementation of both Successor[a] and Ord[a] in scope. The implementation of Ord[a] is required to determine the ordering of the from parameter to the to parameter. Also, the equality relation (defined by Eq[a]) is required to know when the range stops.
object Range {
def range[a](from: a)(to: a)(implicit e: Successor[a], o: Ord[a]): List[a] =
if(o.compare(from)(to) == GT) Nil
else if(o.eq(from)(to)) List(from)
else e.succ(from) match {
case None => List(from)
case Some(s) => from :: range(s)(to)
}
}Suppose we wish to find the range of a list of playing cards. Is it Aces high or Aces low? What about other card orderings used in the myriad of different card games? What about other types besides playing cards? It doesn’t matter, since our range function is as general as it can be. Yay! No more writing the same code over and over!
sealed abstract class Rank
final case object ACE extends Rank
final case object TWO extends Rank
final case object THREE extends Rank
final case object FOUR extends Rank
final case object FIVE extends Rank
final case object SIX extends Rank
final case object SEVEN extends Rank
final case object EIGHT extends Rank
final case object NINE extends Rank
final case object TEN extends Rank
final case object JACK extends Rank
final case object QUEEN extends Rank
final case object KING extends Rank
object Rank {
implicit def acesHigh = new Successor[Rank] with Ord[Rank] {
val ranks = Array(TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, JACK, QUEEN, KING, ACE)
override def compare(a1: Rank)(a2: Rank) = if(a1 == a2) EQ else if(ranks.indexOf(a1) < ranks.indexOf(a2)) LT else GT
override def succ(a: Rank) = a match {
case ACE => None
case _ => Some(ranks(ranks.indexOf(a) + 1))
}
}
implicit def acesLow = new Successor[Rank] {
val ranks = Array(ACE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, JACK, QUEEN, KING)
override def succ(a: Rank) = a match {
case KING => None
case _ => Some(ranks(ranks.indexOf(a) + 1))
}
}
}Notice here that we can bring either acesHigh or acesLow into compiler scope (but not both) and use the range function successfully. Indeed, the following code prints different output because of which function is in scope:
object Main {
def main(args: Array[String]) = {
{
import Rank.acesHigh
Console.println(range(TWO: Rank)(THREE)) // List(TWO,THREE)
Console.println(range(TWO: Rank)(ACE)) // List(TWO,THREE,FOUR,FIVE,SIX,SEVEN,EIGHT,NINE,JACK,QUEEN,KING,ACE)
Console.println(range(ACE: Rank)(KING)) // List()
}
{
import Rank.acesLow
Console.println(range(TWO: Rank)(THREE)) // List(TWO,THREE)
Console.println(range(TWO: Rank)(ACE)) // List(TWO,THREE,FOUR,FIVE,SIX,SEVEN,EIGHT,NINE,JACK,QUEEN,KING)
Console.println(range(ACE: Rank)(KING)) // List()
}
}
}Reader’s exercise: write a range function with step of type Int, which may be negative (and so step backward)
Here is a complete, compilable source code listing:
trait Eq[a] {
def eq(a1: a)(a2: a): Boolean
}
sealed abstract class Ordering
final case object LT extends Ordering
final case object EQ extends Ordering
final case object GT extends Ordering
trait Ord[a] extends Eq[a] {
override def eq(a1: a)(a2: a) = compare(a1)(a2) == EQ
def compare(a1: a)(a2: a): Ordering
}
object Ord {
implicit def intOrd = new Ord[Int] {
def compare(a1: Int)(a2: Int) = if(a1 == a2) EQ else if(a1 < a2) LT else GT
}
}
object Maximum {
def maximum[a](as: List[a])(implicit o: Ord[a]): a = as match {
case Nil => error("maximum undefined for empty list")
case x :: y :: ys => maximum((o.compare(x)(y) match {
case GT => x
case _ => y
}) :: ys)
case x :: _ => x
}
}
trait Successor[a] {
def succ(a: a): Option[a]
}
object Successor {
implicit def intSuccessor = new Successor[Int] {
override def succ(a: Int) = a match {
case Integer.MAX_VALUE => None
case _ => Some(a + 1)
}
}
}
object Range {
def range[a](from: a)(to: a)(implicit e: Successor[a], o: Ord[a]): List[a] =
if(o.compare(from)(to) == GT) Nil
else if(o.eq(from)(to)) List(from)
else e.succ(from) match {
case None => List(from)
case Some(s) => from :: range(s)(to)
}
}
sealed abstract class Rank
final case object ACE extends Rank
final case object TWO extends Rank
final case object THREE extends Rank
final case object FOUR extends Rank
final case object FIVE extends Rank
final case object SIX extends Rank
final case object SEVEN extends Rank
final case object EIGHT extends Rank
final case object NINE extends Rank
final case object TEN extends Rank
final case object JACK extends Rank
final case object QUEEN extends Rank
final case object KING extends Rank
object Rank {
implicit def acesHigh = new Successor[Rank] with Ord[Rank] {
val ranks = Array(TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, JACK, QUEEN, KING, ACE)
override def compare(a1: Rank)(a2: Rank) = if(a1 == a2) EQ else if(ranks.indexOf(a1) < ranks.indexOf(a2)) LT else GT
override def succ(a: Rank) = a match {
case ACE => None
case _ => Some(ranks(ranks.indexOf(a) + 1))
}
}
implicit def acesLow = new Successor[Rank] {
val ranks = Array(ACE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, JACK, QUEEN, KING)
override def succ(a: Rank) = a match {
case KING => None
case _ => Some(ranks(ranks.indexOf(a) + 1))
}
}
}
object Main {
def main(args: Array[String]) = {
import Ord.intOrd
Console.println(Maximum.maximum(List.range(1, 10)))
import Range.range
Console.println(range(7)(8))
Console.println(range(7)(7))
Console.println(range(7)(6))
Console.println(range(Integer.MAX_VALUE)(Integer.MAX_VALUE))
Console.println(range(Integer.MAX_VALUE - 1)(Integer.MAX_VALUE))
Console.println(range(Integer.MAX_VALUE)(7))
Console.println(range(Integer.MIN_VALUE)(Integer.MIN_VALUE + 1))
{
import Rank.acesHigh
Console.println(range(TWO: Rank)(THREE))
Console.println(range(TWO: Rank)(ACE))
Console.println(range(ACE: Rank)(KING))
}
{
import Rank.acesLow
Console.println(range(TWO: Rank)(THREE))
Console.println(range(TWO: Rank)(ACE))
Console.println(range(ACE: Rank)(KING))
}
}
}I recently read an article (on C programming) that made the following claim:
Either f() or g() gets called twice. This is inefficient [where both f and g are equivalent functions.]
Unfortunately, these kind of statements are very common among programmers who generally only use a certain class of programming languages (strict and imperative; C, Java, C# etc.) and I have seen the statement in various forms many times before, but I have been compelled to dispel this myth. I don’t intend to pick on this particular article – after all, the intended topic of the article is unrelated to the fallacious statement, despite being a premise for the article’s conclusions and there are many other writers who are most capable of propagating this misinformation anyway. What the author of this statement might not know is that it contradicts some really interesting branches of mathematics including the Lambda Calculus and Complexity Theory (you may have noticed the lambda symbols in the title of this page and you may have seen the term λ-calculus written before).
The space versus computation trade is a standard problem for computer scientists, but recent industry trends have generalised this problem to the point of actually not appearing like a problem at all. You see, space has become cheap, really cheap – so cheap that it almost appears infinite. Let us consider the problem of finding the nth element of an array and a linked list. For the array, this will execute in constant time, however, for the linked list, the time to compute it will depend on the value of n. Notice how the array exists in-memory while the linked list might not (e.g. it may read from a file as it is traversed). That is, it has incurred a space cost. This cost has provided the benefit of computation speed. A trade has occurred, not an efficiency gain.
The use of the linked list is called lazy evaluation (or laziness) while the use of an array is called strict evaluation (or strictness). Traversing the linked list is sometimes called thunking (which is just an obscure word for invoking a function) and evaluating each of its elements is called Weak Head Normal Form (WHNF), which is a term taken from the λ-calculus.
Given a lazily evaluated structure, it is possible to make it strict by bringing it to WHNF. This computation will occur once and its result may be placed in a universally-available table with constant time lookup to prevent computing the value again. This storage will incur space and is a process called memoisation. Unfortunately, a strict structure cannot be made lazy since the space cost has already been incurred. In fact, doing so yields no benefit whatsoever (other than to appeal to a type system).
We can observe laziness and strictness in some of our poor-yet-popular programming languages like Java, where an array represents a strict, homogenous list, while an InputStream or Iterator represents a lazy list. A ByteArrayInputStream is a (unfortunate) attempt to construct a lazy structure from a strict one with no additional benefit – in this case, it is to appeal to a type system (e.g. to use a method that must accept an InputStream instead of a byte[]). A Haskell list, which is lazy, is more like a Java iterator than a Java list or array (but still with a significant difference) and it is often better to think this way if you are learning a lazy language coming from a strict, imperative language. In fact, like a Haskell list, a Java iterator can have an infinite length where its hasNext method never returns false.
We can see now that if f() or g() gets called twice, then this is not inefficient, nor is it efficient. This is actually a trade. Computation has been spent while space has been gained, since the result of the computation of the first call of either function is not stored, but is recomputed. Similarly, purchasing a bottle of water for one dollar is not more or less efficient, assuming that the bottle of water is indeed worth one dollar. You are no more or less better off whether you purchased the water or not. Of course, we rarely see such purist forms of capitalism, but the analogy makes sense otherwise :)
Programmers of strict, imperative languages do not always elect to strictly evaluate from what is called a universe (or domain) of discourse (from Set Theory). That is to say, from the universe (U) that is passed to the programmer, each expression is not necessarily brought to WHNF. Ideally, only what is necessary is evaluated to complete the computation and anything else from U is left untouched, however, the decision of what to evaluate is often (at least in my observations) totally arbitrary due to a lack of formal reasoning and inexperience with the foundations of computer programming – on the part of the programmer. If a subset of the universe is evaluated that is never needed to complete the computation, then this is an inefficiency and it happens very often in strict, imperative languages. (Think tip: Is it any wonder your Java application consumes all your volatile memory?)
Let’s demonstrate this. Suppose a Java programmer is asked to compute an int – the sum of the first 2 bytes from an InputStream, or compute 1024 if the bytes are not available. The InputStream represents a potentially infinite universe of discourse (|U| = ∞), however, not all of it is necessarily evaluated (if it were infinite, the function would never terminate). Here is a canonical solution:
int firstByte(InputStream in) throws IOException {
final int i = in.read();
final int j = in.read();
return i == -1 || j == -1 ? 1024 : i + j;
}Notice how the entire InputStream is not read until the end (if there is one), simply because you can, since this would be an inefficiency. The domain or universe is an InputStream, but only two reads occur. Indeed, if this InputStream were infinite, the function would still terminate. Similarly, the following equivalent Haskell function will terminate:
let first (i:j:_) = i + j; first _ = 1024…even if passed an infinite list:
> first [20..] -- from 20 to infinity
41If a byte[] were passed to the firstByte function instead and the entire array were never evaluated for the computation (why would it?), we would have an inefficiency. If the array was fully evaluated during computation, then we have neither an efficiency, nor an inefficiency. Certainly, evaluating beyond the universe of discourse yields no benefit whatsoever while incurring a space cost. Unfortunately, this is not immediately obvious because poor-yet-popular programming languages sometimes make it cumbersome to write the desired expression without incurring this inefficiency and so it appears as if it were a necessary trade with the language itself. That is, the reasoning “because this language is cumbersome to such an extreme, it will force you to incur inefficiencies by evaluating outside your domain for computation so as to avoid writing code that is cumbersome” is often overlooked, typically because the alternatives are not known. Also, the more elegant solution, even in that cumbersome programming language, is often overlooked. Nevertheless, I find this behaviour of both the programming language and the programmer using that language, completely absurd (I love you Alex ;))
However, languages such as C/Java often make laziness very easy. Suppose you write an if/else. The runtime will not evaluate both the if and else block before executing one or the other. This is lazy behaviour. Similarly, the ternary operator (?:) is also lazy. Finally, the && and || operators are also lazy, since their second argument is only evaluated on-demand. Therefore, we see clearly that laziness is not a completely foreign concept to (mostly :)) strict, imperative languages and is often preferred, since the contrary may certainly result in an inefficiency.
I leave now with the following transcript from my GHC/Haskell interpreter (which is inherently lazy):
> take 5 [1..] -- take the first 5 elements from the list of 1 to infinity
[1,2,3,4,5]
> foldr (&&) True $ repeat False -- fold the conjunction of True and an infinite list of False
False
> foldr (||) False $ repeat True -- fold the disjunction of False and an infinite list of True
True
> -- foldr (||) True $ repeat False -- eek! this will never terminate!
> take 5 $ map (*2) [1..] -- take the first 5 elements from the list with the function (*2) mapped across 1 to infinity
[2,4,6,8,10]On 28 April 2006, I was charged by a police officer for obstruction under Police Powers and Responsibilities Act 2000 Section 444 (since amended to Section 790). The police officer alleged at the time that my holding of a sign that reads ‘Police Speed Trap Ahead 50’ – with emphasis on the 50 indicating the speed limit in that area – constituted an offence, obstruction.
I subsequently entered a plea of not guilty (after one adjournment) and made several attempts to obtain a Brief of Evidence from the police prosecution. Their incompetence would normally astound me, but these days I just roll my eyes – in fact, a demonstration of competence itself would invoke surprise (know of one?). Of course, no brief was available, for days, then weeks, then months and in the meantime, I had spent countless hours on putting together a defence.
Finally, the day before the trial, still without a brief (roll eyes now), the police prosecutor rings me and attempts to negotiate – in the usual friendly/manipulative manner as expected. After the usual banter (trying to obtain information from me), I am offered a ‘guilty plea for no conviction’ deal, which I immediately decline and hang up the phone with, ‘see ya tomorrow mate’. I then travelled to the police station to request a brief of evidence, knowing I wouldn’t receive one, but adding to my record of attempts to obtain it, that I would be presenting to the magistrate the following day. A couple of hours later, I receive another phone call to be notified that the charge has been dropped.
This occurred for two reasons.
The police prosecution was too incompetent to get their act together to pursue the charge
But most importantly, the police do not want to set a legal (lawful) precedent for this behaviour
The police prosecution clearly believed that there was a strong possibility that my not guilty plea would pay off. If it were successful, a subsequent appearance on television (see the first one below) would have propagated the legality of this activity among the public and the police definitely do not want an informed public even if it means that I ‘get off’. Instead, it is best to leave the issue ‘blurred’ and continue pursuing ‘offenders’ such as myself, who otherwise do not know any better and enter a guilty plea on the day in court (I understand that many police officers genuinely believe that they are performing a public duty, but let’s leave that side issue).
Although I am not a lawyer, this activity is not illegal if it is executed correctly. I encourage any member of the public who is concerned about road-safety in Australia to engage in this lawful behaviour, although I do not accept any liability for any adverse consequences that you may encounter, including, among other things, a criminal conviction.
To engage in this behaviour legally in Queensland (other states may be similar), ensure the following:
stand well away from the police speed trap, a few hundred metres at least
if approached by anyone, do not offer comment under any circumstances
if approached by a police officer, he/she may request your name, address and may also request “evidence of the correctness of the stated name and address” (see PPRA2000 Section 40)
Comply if you are asked for name and address, but under no circumstances should you offer further comment on the matter – police are very well trained at extracting this information to ensure your conviction, so it is up to you exercising discipline to keep yourself safe. This request is almost certainly a demand under PPRA 2000 Section 41 where the police officer “reasonably suspects the person has committed an offence”, even though you probably haven’t. Do not pursue this ambiguity with the police officer at the scene.
What about flashing vehicle headlights? If you flash your headlights to warn other motorists of an impending speed trap, a police officer will almost certainly issue you with an infringement notice of Rule 218 of the Australia Road Rules (Transport Operations Regulation 1999 in Queensland). It is important in this case to fulfill your legal obligations (name, address and produce valid driver’s licence) but offer no other comment – why? Because you may not have committed an offence, that’s why.
Let’s take a look at Rule 218 of the ARR (Part 13 Division 1):
218 Using headlights on high-beam (1) The driver of a vehicle must not use the vehicle’s headlights on high-beam, or allow the vehicle’s headlights to be used on high-beam, if the driver is driving: (a) less than 200 metres behind a vehicle travelling in the same direction as the driver; or (b) less than 200 metres from an oncoming vehicle. Offence provision. Note High-beam and oncoming vehicle are defined in the dictionary. (2) However, if the driver is overtaking a vehicle, the driver may briefly switch the headlights from low-beam to high-beam immediately before the driver begins to overtake the vehicle. Note Low-beam and overtake are defined in the dictionary. Diagrams follow
Your infringement notice is for part (1) of Section 218, but a police officer almost certainly will not ask you if you used your signals for part (2). Have you ever asked yourself why ADR (Australian Design Rules) compliant vehicles have a high-beam flasher switch? Of course, because it is entirely legal to flash your high-beam headlights under some circumstances.
If you wish to warn opposing traffic of an impending speed trap, ensure that you flash your headlights under legal circumstances – while overtaking a vehicle, briefly from low-beam to high-beam and immediately before overtaking the vehicle. Do not feel tempted to justify this action on the side of the road with a manipulative police officer! Simply enter your not guilty plea in the court and explain to the magistrate that you were acting legally and responsibly under Rule 218 of the ARR.
I recently noted that I’d had stitches in 23 sites on my body – including, among other things, an amputation of my right-index finger. It was last Saturday (17 Feb 07) that I was training as usual at my squash club, when I was struck just above the eye by the end of my opponent’s swing, drawing lots of blood as you would expect with an elevated heart rate during squash and sending my opponent into mild shock at the sight of it (te he :)).
Anyway, my count still remains at 23 – why? Because the emergency department used glue! I suppose the injury was not large enough to warrant the use of sutures, but glue!? Who’d uv thunk?! It has healed perfectly and my first match in this weekend’s Charles Butcher Tournament starts in a couple of hours. Revenge is definitely on the agenda! Watch your back Brad :)
Quite often, I hear comments from people who are trying to get a grasp on functional programming about entities which are “inherently stateful” or “intrinsically mutable” (example). The commenters often point to a disk or network to make the point. In this post, I am going to attempt to portray a slightly deeper understanding of this topic to erase the facade and bring to fruition the fact that this “inherent state” (or whatever) is in fact an illusion. This will require some thought experiment and the manipulation of some abstract entities in order to attain this insight.
I will first start off by describing the distinction between the physical universe as we observe it and the abstract universe. The physical universe is made up of matter; for example, a house, a typewriter and even a hard disk. The abstract universe is one that is, well, abstract – one that is not physical. If we consider the number 2. We call it ‘a number’, a physical entity, yet we cannot hold it in our hands or point to its physical representation. Therefore, 2 is better described as a representation of “twoness” or “the concept of two”. The symbol ‘2’ is used to denote the concept of two, among other possible representations of the same concept:
two
. .
00000010
…and so on. Anyone interested in defining the concept of two, with a bent for history, might be interested in learning about the discovery of zero.
Now, this point touches on some philosophical grounds that I’d rather not go into, so instead, I will make a note of the fact that a pure evolutionary Atheist might not accept this distinction (perhaps claiming that 2 is in fact physical as a chemical signal in the brain), while a Theologian would describe the abstract universe as your ‘Soul’ (or some such). I don’t mean to encroach on this philosophical point and I am hoping I can get away with using terminology that can be translated to the relevant philosophical view.
So, when you write a function, in any language, f(2), you’re not passing a 2 or 2 itself to that function, but instead, a representation of the concept of two to the concept of your function and nothing further. Here’s the clincher: All software exists in the abstract universe. Even your C program that does clever pointer arithmetic and your assembly program that moves the hard disk head. Yes, that FILE* is in fact, an abstraction of a pointer, not a pointer itself. None of these are physical entities, but abstractions of physical entities that manifest themselves somehow – none of these manifestations are relevant to the software author.
It’s all quite simple so far, but if you can pass ‘a representation of the concept of two’, then what is to stop you from passing ‘a representation of the concept of the file system’? or the network? Nothing, that’s what. In fact, you could quite plausibly argue that this is exactly what Haskell’s IO monad is doing – an abstraction that represents these physical entities using the expressive type system of Haskell. In exactly the same way that 2 is an abstraction that represents a physical entity i.e. it will eventually manifest itself as electrical signals in your computer hardware (or physically manifest somehow anyway).
Those of you who are concerned about passing an entire file system as a function argument and the impact on performance might be interested in delving further into a topic called Lazy Evaluation and Weak Head Normal Form (WHNF). I’d rather not reiterate the work of many others who are more dedicated, so I’ll just point out that concerns for performance are definitely valid, but the impact on performance is not there (in fact, often quite the contrary – performance improves!).
The distinction between ‘2’ and ‘the file system’ and ‘the network’ from a software developer’s perspective is entirely superficial and should be abandoned. One cannot be ‘inherently stateful’ while the other isn’t. It’s one or the other, so which is it? (hint: n**ther :))
Ask your average Java (or C#) programmer to ‘write a method that takes a list of integers, adds 10 to each element, converts the result to a String, prepends * to it and returns the resulting list’. It’s quite easy and you can certainly postulate what kind of start would be made on this. Here is how I suspect most Java programmers would solve this problem:
...
static List<string> addTenAndConvert(List<integer> list) {
List<string> result = new LinkedList<string>();
for(Integer i : list) {
String s = "***" + String.valueOf(i + 10);
result.add(s);
}
return result;
}Simple enough. Many people would also write so-called ‘unit tests’ to assist in verifying that the method meets the specified requirement. It is interesting to note at this point that ‘for all’ (hint) list arguments, the length of the return value will always be equal. So for the argument, {1,2,3} with a length of 3, the result is {“*11", "12", "**13”} also with a length of 3 and this property holds across all lists.
But then, I ask for another method that does all the same, but this time, prepends “AAA” instead of “*”. Whatchya gunna do? Copy/paste/change? No, you’re going to refunctor (to be defined in time to come), that’s what. You might pass an additional argument of type String and prepend that. Sounds fair enough. But then I will ask instead that you append “BBB” instead of prepending “AAA”. Pass an additional argument of type boolean?
Let’s take a look at what we’ve got:
...
static List<string> addTenAndConvert(
List<integer> list, String s, boolean prepend) {
List<string> result = new LinkedList<string>();
for(Integer i : list) {
String ss = prepend ? s + String.valueOf(i + 10) :
i.toString() + s;
result.add(ss);
}
return result;
}But then, I ask you for another requirement – this time devastating. I ask instead that it is not a List argument, but a List argument and a List return type. Going to copy/paste this time, right? The conversion from each String element to the new Integer element is left unspecified for now, but feel free to dream something up. In fact, feel free to ‘refactor’ it out:
interface Convert {
Integer convert(String s);
}…then change the method like so:
...
static List<integer> stringListToIntegerList(
Convert c, List<string> list) {
List<integer> result = new LinkedList<integer>();
for(String s : list) {
Integer i = c.convert(s);
result.add(i);
}
return result;
}Notice that our method’s name is becoming less specific as it is refactored and becoming more abstract in behaviour. Further, we cannot write our method addTenAndConvert in terms of our method stringListToIntegerList by passing a different implementation of Convert because our types do not match. However, notice that the transformation on each list has nothing to do with specific types – these types are actually unbounded polymorphic types. Let’s try again.
interface Convert<T, U> {
U convert(T t);
}
static <T, U> List<u> fooForNow(Convert<T, U> c, List<t> list) {
List<u> result = new LinkedList<u>();
for(T t : list) {
U u = c.convert(t);
result.add(u);
}
return result;
}How’s that look!!? What shall we call this method? I have called it fooForNow, but if you’ll just let me call it map instead, just because. We can now write our method addTenAndConvert with our newly found abstraction – the map function:
static List<string> addTenAndConvert(List<integer> list) {
Convert<Integer, String> c = new Convert<Integer, String>() {
public String convert(Integer i) {
return "***" + String.valueOf(i + 10);
}
};
return map(c, list);
}How funky is that? Funky enough for you to start looking at funktional programming? I’ll let you in on a little secret. This relatively high euphoric point of using Java/C# (et. al.) is the very basis and starting point of most functional programming languages. In fact, the map function is typically included in the standard libraries! Functional programming is Java version 42, seriously. It is a natural extension to what it is that most Java/C# programmers are already doing. It is not some esoteric, orthogonal, unrelated paradigm that has nothing to do with anything except the point of singularity.
If we consider our Convert type to actually represent ‘anything that can convert a T to a U’, we call map a higher-order function, since it takes a function (from T to U) as an argument. Whether or not to name this function argument (to Convert in our example) and hide the behaviour of this conversion behind some implementation sets the premise for the ‘DD (Dynamic Dispatch) versus HOF (Higher-Order Function) issue’.
If we look at the type for the Haskell map function, we see it like this:
map :: (a -> b) -> [a] -> [b]That is, as the first argument, it takes a function from a type ‘a’ to a type ‘b’ (we called these T and U, but Haskell type parameters must be lower-case). The second argument is a list of the type ‘a’ and the return type is a list of the type ‘b’. That’s exactly what we just wrote in 43 trillion lines of Java code! OK, maybe I am exaggerabating a bit there.
And in case you’re wondering, here is how addTenAndConvert looks in Haskell:
let addTenAndConvert = map (("***" ++) . show . (+10)) -- tidy eh?Why ‘Refunctoring’? First, I refuse to reuse euphemistic terms that have served only to denigrate the standard of the software development industry, therefore, I cannot use ‘Refactoring’ (oooh! did I just say that!!?). To show this, consider the fact that the entire notion of ‘Refactoring’ is done away with one simple phrase ‘Functional Programming’ in the case shown and hundreds more. Of course, you might decide to redefine Refactoring to a different context, but then, redefining terms often leads to confusion (the term ‘function’ is itself a perfect example). To further demonstrate this point, open the book or catalog on Refactoring and turn to the section titled, ‘Replace Parameter with Method’. Then say out loud, ‘partial application’ – if you don’t know why you’re saying that, learn what partial application is, then perhaps it might dawn on you. A useful exercise is to apply this technique to all so-called ‘Refactorings’ and see how many are eliminated by existing programming techniques that don’t get very much air time in advertising material (though, this might be changing thankfully). More useful might be to see how many are left standing (want to know my conjecture?).
Anyway, Refunctoring is what most people really are doing. They are converting their code that is written in not-too-powerful programming languages to mimic the power that is already available in functional programming languages. They are representing higher-order functions with (importantly, co-variant) polymorphic type parameters, refactoring out what partial application already provides and much more. This is being done, despite having been invented many, many years ago, but the fact that it is being done mandates a name, albeit how absurd it might be. I use the term Refunctoring, for no other reason than it was suggested to me by a bemused colleague (you know who you are :)) one day and upon reflection, I have decided that it is entirely appropriate.
You don’t think the map function is a special case do you?
I have been using Scala for the past few weeks to write a web framework that ‘fixes’ the convoluted Java Servlet Specification. I have succeeded in doing so and I have a prototype running on Apache Tomcat right now as I write this post, however I didn’t get to this point easily; not without first having to do such things as:
write a lazy cons list without any methods declared on the type – rather, functions over the type that are declared in a Scala object (roughly analogous to Java static methods)
conceding to using mutable state/destructive update at some points – particularly converting strict and/or side-effecting Java types to nice, lazy, pure types
missing out on the syntactic niceties that monads provide – Scala does not support higher-order kinds
Scala is what I consider a very pragmatic (to steal a buzzword from the hype generators) approach to software development as it exists today. It satisfies the incompetent assertions of the illegitimate authority (aka management) – “you must use Java (et al.)”, while still allowing a reasonably concise expression and programming paradigm e.g. Scala has pattern matching, case classes, variance annotations, higher-order functions and implicit defs (similar to Haskell type-classes). These features alone dramatically reduce the amount of repetitious work that you otherwise do in more mainstream languages by one of those crazy orders of magnitude that would never be believed by a mainstream programmer and so could easily be explained away as nonsense with support from other ill-informed peers (those who know what I mean, know what I mean).
I had read about CAL, but didn’t ever give it much consideration until today. And it is today that I realise that my blissful ignorance has cost me. CAL is very Haskell-like with full support for using Java types (just as Scala does) and compiles straight to the JVM (just as Scala does) – making up for the deficiencies of the Java runtime compiler using techniques such as tail recursive call elimination (again, just as Scala does).
However, upon further reading (I admit to not having used it in great detail just yet), CAL does more – much more. It is lazily evaluated and it is pure functional. It has higher-order kinds and we know how important that is. It has monads and even the Monad data type subtypes the Functor data type! Not even Haskell does that (though I’m sure things would be different given hindsight ala CAL)! Type parameters are covariant, given its pure functional nature and it makes expressing strictness much easier than it does in other lazy languages (apparently). Of course, this is all potentially a reiteration of hyperbole, since I’ve yet to try it out – but it does look promising, especially given that it has now been released under a BSD licence.
The point is, my ignorance (of CAL) has cost me, since I have a well thought-out, very usable web application framework (sorry HAppS) that has been written in a possibly (probably) inferior language. Here I was thinking I had the best of both worlds – satisfying the pointy-haired boss, while still getting on with writing software. Though, it could be worse, much worse – I could have written it in Java/C# like many other participants in this circus are doing.
I have 2 children, (almost) 6 and 4 years old, who have recently come under attack by the pawns of an elitist minority-led Christian organisation that is supported by our government and other elitist organisations. The sad part is that these so-called ‘pawns’ are unaware that indeed they are acting as pawns. The internalisation of the legitimacy of their ignorant stance has surpassed the point of conscious denial and is so prolific, that I very much doubt that this realisation will ever come to fruition. Despite this sad state of affairs, I must maintain the well-being of my children – at all costs – and this may require the absolute refusal to permit even the most remote hint of indoctrination of the purported filth to my children who are in no position to defend themselves against it. The persistence of the manipulators, and most importantly, those being manipulated, often requires quite a fervent and directed response from me – the protector of my children.
I am writing this post to address these people who are conducting these attacks, even though I know that it is probably futile, given their own lack of recognition of their actions. You may accuse me of “not giving my children a chance to make up their own mind” or blatantly disallowing established beliefs, despite their widespread proliferation. I accept these allegations, thank you for your (no doubt conscious) concern, but reject the legitimacy of the accusations, without further explanation. Unlike the religious establishment, free thinkers have absolutely no problem whatsoever shifting position in light of compelling evidence. My children are, and will be, free thinkers and your actions are detrimental to this objective. I withdraw any attempts to justify my position, not because I am arrogant or have some kind of personal conviction with my stance – simply, I do not wish to engage in your war. Call me Switzerland, call me a coward, call me whatever, heck, cast me to a furnace for eternity, but please don’t do it in front of my children. Please (oh please) understand.
Nevertheless, to express my dissent and fear for the well-being of my children is not the primary objective of this post. Instead, it is to express a common misnomer. Often times, I am accused of undermining the value of those who conduct blatant attacks with their irrational beliefs as human beings. Please be assured, I do not think less of you than another, even myself. You are an equal.
Some people don’t like pain – when they watch someone else smack their head on a tree, they cringe with empathy. In fact, if the poor victim could be warned of the impending danger somehow, I am sure that an empathetic person would make every effort to make it the case to prevent the infliction of pain. This is exactly my response to those who have been robbed of the ability to think critically. I have absolute, paramount sympathy for your position, well beyond that of any other position that I could possibly imagine – even extreme pain (I have had stitches in 23 separate sites on my body, including one amputation and one ‘sewing it back on’ – I have felt pain).
Please also be assured that my response to the attack of my children must take priority over the expression of this sympathy. My response may appear to be in complete contradiction to what I have just declared – but it is not the case universally. I must put aside my own self-indulgences in expressing sympathy when protecting my children – they are just so vulnerable and trusting.
Please, please understand, just for a brief moment even.
“None are more hopelessly enslaved than those who falsely believe they are free” -Johann Wolfgang von Goethe …and they receive my sincere condolences for the loss of control of their own mind.
Coming from an imperative language such as Java/C/C# and moving to a functional language, you will almost certainly encounter ‘folding functions’. There are usually two folding functions (sometimes there are minor variants) – one folds to the right and the other folds to the left. In Haskell, these functions are named foldr and foldl.
This first encounter with folding functions can often be quite daunting, but I propose an alternative approach. In fact, these folding functions are almost certainly quite familiar to the imperative programmer – just without consciousness. If I had a dollar for every time I saw something like this (I’d buy every CS student a book on the lambda calculus :)):
...
B accum = b;
for(final A a : as) {
accum = f.f(a, accum);
}
return accum;Look familiar? Not so daunting? Great, because it’s a fold – specificially, a fold to the left. It is a fold to the left because the sequence (list, array, whatever) is iterated from the left/start to the right/end. Conversely, a fold right iterates from the right/end of the sequence to the left/start.
Let’s take a closer look at the ‘fold left’ above. The first line initialises an accumulator of type B to the given argument. Then the sequence (of A) is iterated and each element is passed to some function and its result assigned to the accumulator. Finally, the accumulated value is returned.
Have I just trivialised a seemingly complicated concept? Not at all! I have undermined its apparent complexity perhaps. On the contrary, it is the imperative language version that has complicated a trivial concept. Let’s take a look at a complete and compilable example:
class Foldr {
static interface F<A, B> {
B f(A a, B b);
}
static <A, B> B foldr(final F<A, B> f, final B b, final A[] as) {
B accum = b;
for(int i = as.length - 1; i >= 0; i--) {
accum = f.f(as[i], accum);
}
return accum;
}
}
class Foldl {
static interface F<A, B> {
A f(A a, B b);
}
static <A, B> A foldl(final F<A, B> f, final A a, final B[] bs) {
A accum = a;
for(final B b : bs) {
accum = f.f(accum, b);
}
return accum;
}
}
public class Folds {
public static void main(final String[] args) {
final Integer[] i = new Integer[]{7,8,9,42,11,13,45,54,45,46,64,74};
final Integer right = Foldr.foldr(new Foldr.F<Integer, Integer>() {
public Integer f(final Integer a, final Integer b) {
return a - b;
}
}, 79, i);
System.out.println(right);
final Integer left = Foldl.foldl(new Foldl.F<Integer, Integer>() {
public Integer f(final Integer a, final Integer b) {
return a - b;
}
}, 97, i);
System.out.println(left);
}
}Phew! What an effort – pass me a beer!
We notice in the main method that the types of both A and B are the same (Integer). This is purely consequential and these types may, and often do, differ. Also notice that our function in each case is not commutative. That is, f(a, b) is not necessarily equivalent to f(b, a). We know this because a - b is not necessarily equivalent to b - a. If the functions were commutative, then the result of a fold right would be equivalent to the result of a fold left. If you execute the code above, you will not get the same output for each fold. Try changing the implementation of each function to be commutative (like +) and observe the equivalent results.
Let’s take a look at the Haskell equivalent at an interpreter:
Prelude> let i = [7,8,9,42,11,13,45,54,45,46,64,74]
Prelude> foldr (-) 97 i
41
Prelude> foldl (-) 79 i
-321Same outputs as the imperative code? Good, so that’s folds out of the way – easy peasey :)
By the way, yes the Haskell equivalent is supposed to be 100 times shorter – that is the nature of a relatively expressive programming language.
I have been reading articles lately that make a case for or against ‘strong type systems’ by referring to artifacts that purport the exact opposite of a strong type system such as Java, C/C++, C# or a few other weak type systems. This is unfortunate, since the remainder of the article becomes immediately invalid within the first two or three sentences and I doubt that the author is even aware of the fact that they are wasting their own time while at the same time, misleading any potential readers. Quite often, these articles have trendy or appealing writing styles, such as “Parabola”, which attempts to universally refute the legitimacy of type safe (T.S. in the article) systems by making a rather clever, albeit erroneous, metaphor with a scenario in an airport.
There are countless articles that talk about the problems with null, but is this a problem with type systems? No, it is a very poor solution to work around one of the fundamental contradictions that plagues imperative programming. That is, even if we must keep this contradiction and imperative programming for some reason (which we don’t), there are better solutions than null. So this leaves a problem for any author who wishes to provide a higher understanding for their readers; do they explain all the problems with null in more formal, concise and correct terms knowing that the whole problem disappears with a better foundational grounding (eliminating imperative programming), or do they simply present some alternatives that may be unfamiliar and hope for initiative on the part of the reader who will use (the ever so common) gut instinct to feel that they have a superior solution? A horrible problem that is thankfully not mine.
Just what denotes Java et. al. having a weak type system? On what basis is this statement made? The answer to this question is not trivial by any means and answering it requires a reasonable amount of foundational mathematics knowledge, which leads to specialisation in type theory – both of which not many software developers have, nor have the initiative to acquire (this is sad :(). In any case, a brief attempt can be made. There is no doubting that these weak type systems disallow a certain amount of expressivity and force a rigid and sometimes unreasonable method of development. That is not to say that dynamic typing is the solution. Just like Dawkins said that since the beginning of life is so improbable as to be impossible (on the surface), then the existence of a supernatural creator is not the only alternative solution – referring to Darwinism. Whether or not you believe in a supernatural creator, it would be obscene and somewhat ignorant to immediately jump to such a conclusion without rational reason – such as critically analysing alternatives. Likewise, it is obscene to jump to the conclusion that dynamic typing solves the problems of (weak) existing type systems without considering alternatives, such as expressive type systems.
Using Java et. al., it is impossible to express certain fundamental programming concepts and many more concepts that are specific to the problem at hand. One such fundamental programming concept is the monadic bind computation. Before I start going into detail about this, I am compelled to first dispel a very common myth. Many ‘programmers’ believe that monads (and therefore, monadic bind) are not relevant to their problem, since their language does not support such a concept directly. Few programmers actually realise that they are in fact using monads, just without language support and often in a somewhat contrived manner – a result of the lack of formality in reasoning. In fact, I postulate that in my time working on IBM WebSphere 6 and the IBM JDK 1.5, I saw somewhere in the order of hundreds of monads littered throughout thousands of lines of code. Furthermore, Java/C# has one particular monad built right into the language. Providing concrete examples is worthy of a topic on its own, so I will instead take the liberty of claiming that if anyone were to send me their 2^gazillion LOC application, I would be capable of finding one monad per one thousand LOC – worst case scenario. At least, please assume so for now. Yes, monads are extremely important and common to programming, even if you don’t ever know it explicitly. Great, glad that is out of the way :)
We cannot express monadic bind with these weak type systems because they do not have higher-order types. What is a higher-order type? A few people with much more time, specialisation and knowledge have done a better job than I am at least willing and probably capable, of doing. Instead, I will attempt to demonstrate what happens when you attempt to generalise monadic bind with a weak type system. Haskell is a purely functional language that does have higher-order types. If we ask a Haskell interpreter for the type of bind (>>=), we get the following:
Prelude> :type (>>=)
(>>=) :: (Monad m) => m a -> (a -> m b) -> m bThis is akin to a Java/C# interface (called Monad) containing one function (>>=) or ‘bind’, however, we will note that there is no analogy for this expression in a weak type system. This fact, along with many others, seems to be quite a hurdle in grasping the very concept of the bind computation itself. If we examine this type expression, we could say that the bind function (>>=) takes two arguments:
a monad with a type parameter ‘a’
a function from ‘a’ to a monad with a type parameter ‘b’
The function returns a monad with a type parameter ‘b’. ‘Implementing this interface’ would make the class itself an instance of Monad and so itself can be used as the function arguments. This is one of many things that higher-order types gives us.
Let’s attempt this with a weak type system, Java. First, we acknowledge that Java has no first-class functions (cannot pass functions as arguments), but we can loosely emulate it (good enough for our purposes) with a single interface:
interface F<X, Y> {
Y f(X x);
}Let’s attempt to write the Monad interface:
interface Monad<A> {
<B> Monad<B> bind(Monad<A> ma, F<A, Monad<B>> f);
}Looking good so far. But don’t be fooled – there is a huge problem. Namely, that the interface cannot be implemented correctly. Keeping with tradition, let’s attempt to write the Maybe monad:
final class Maybe<A> implements Monad<A> {
// BZZT! WRONG!
Maybe<A> bind(final Maybe<A> ma, final F<A, Maybe<B>> f) {We hit our first problem, can we work around it? In Java, we have co-variant return types, but we do not have higher-order types. This means that we can keep our return type declaration, but not the types of our arguments – they must match the interface. Then, we can resort to casting – an abomination that indicates a flaw of the type system.
Let’s try again:
final class Maybe<A> implements Monad<A> {
public <B> Maybe<B> bind(final Monad<A> ma, final F<A, Monad<B>> f) {
if(ma instanceof Maybe) {
...This solution works, but we have to admit to having to work around the type system by resorting to casting. As a result, I will no longer call it a solution, but instead, it is a work around – a flaw in the expressitivity of the type system. The lack of higher-order types in common type systems is one of many problems with quite devastating consequences. In attempting to model a fundamental computational concept, we find that the type system of Java (and many other programming languages with weak type systems) is not a sound premise from which to extrapolate conclusions about type systems in general. If we were to do so, we would be making a fundamental mistake. In fact, this particular problem is one that dynamic typing appears to solve. But don’t let these superficial appearances delude you. A stronger type system is the correct solution.
Here are some conclusions from these findings:
Higher-order types are fundamental to a strong type system
Java/C/C++/C# et. al. do not support higher-order types, therefore, do not have a strong type system
Monadic bind is a relatively trivial, yet extremely common programming concept
Monadic bind cannot be easily expressed in common weak type systems
Dynamic typing is not the only apparent solution to resolving the problems of weak type systems
Here are some questions to ponder:
What if we tried to model a concept that is not as trivial as the bind computation? Does the difficulty of expression grow linearly to the complexity of the concept?
What other concepts are supported by strong type systems but not our common weak type systems?
Can we come up with other examples of common, trivial concepts that cannot be expressed because these weak type systems are missing some other feature besides higher-order types?
Most importantly, what does a comparison between a type system that exemplifies sound, strong and expressive type safety with dynamic typing (or no typing) give us?
It is this latter question that needs to be explored before drawing any potentially misleading conclusions about type systems. It is a crucial mistake to make a comparison to weak type systems that do not in any way exemplify soundness, as anything else but unsound examples of type systems. The implication that dynamic typing is a correct solution is a blind-man’s fallacy.
A compilable solution follows:
interface F<X, Y> {
Y f(X x);
}
interface Monad<A> {
<B> Monad<B> bind(Monad<A> ma, F<A, Monad<B>> f);
}
final class Maybe<A> implements Monad<A> {
public <B> Maybe<B> bind(final Monad<A> ma, final F<A, Monad<B>> f) {
if(ma instanceof Maybe) {
final A j = ((Maybe<A>)ma).just();
if (j == null) {
return new Maybe<B>();
} else {
final Monad<B> b = f.f(j);
if(b instanceof Maybe) {
return (Maybe<B>)b;
} else {
throw new Error("Just because we don't have higher-order types," +
"doesn't mean we start doing silly stuff");
}
}
} else {
throw new Error("I said stop doing silly stuff! Please!");
}
}
// Let's just hack for now.
// null denotes 'Nothing'.
// Many programmers will be familiar
// with this idiom (did I say hack?)
// anyway.
//
// A more complete solution is provided at
// http://blog.tmorris.net/revisiting-maybe-in-java
private final A a;
public Maybe() {
this.a = null;
}
public Maybe(final A a) {
this.a = a;
}
public A just() {
return a;
}
}While the Dawkins argument against Agnosticism is the usual and incredibly weak and contradictory proposition with a touch of cognitive dissonance (sound familiar Dawkins?), I must otherwise extend an overriding congratulations and approval of any concise, calculated and importantly, successful, attack against Abrahamic theism. I strongly urge anyone of any faith to consider The God Delusion if only to learn what “all the fuss is about”, but do approach with extreme scepticism - as I’d imagine Dawkins himself would recommend.
I generally don’t like to dabble in silliness that can be easily misconstrued as elitist (or some other negative label), but nevertheless, I feel compelled to record what I believe is the most ironic logical proposition that is available on the internet. I am not recording this so that we can all point and laugh or anything mindless like that, but instead, to reflect on just how easy it is to make a crucial mistake in judgment particularly when you least expect it. I believe that the irony of this statement supersedes that of any propositions that have exited from the mouth of President Bush or any other equally vulnerable world leader, etc. though many have come close.
If we pop on over to a document titled, Beating the Averages, we find a proposition (or assumption for the remainder of the section) that is somewhat striking. Here it is:
Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available.
I have lost a little bit of the context in citing this statement, so I encourage anyone to read the full script. The irony lies in the fact that the author (Paul Graham) sets about describing what he calls the “Blub Paradox”, which is defined by how computer programmers can only look back at what they once knew about computer programming languages, but cannot make sense of what might be ahead - or might not even be aware that there is anything ahead! What the author probably does not know, is that in attempt to describe the “Blub Programmer” in the third person, he has inadvertently labelled himself a Blub Programmer by his very own definition.
I wonder if Mr. Graham has learned of this mistake, but I sure hope someone points it out to me if (when) I make it! :)
This is a call out to renew pressure for Sun to fix the tail call elimination defect/RFE that has existed in HotSpot since inception and still exists today. The IBM JIT is very much capable of tail call elimination, as is the .NET CLR (it even has an instruction built-in!) but still Sun’s weak compiler dominates our industry and stifles further innovation in software development.
It has long been known that imperative programming has some inherent weaknesses and people all around the place, who recognise this weakness, are trying to remedy it, only to be stopped in their tracks by the fact that this industry continues to use a very poorly implemented compiler.
Today, fixing this defect is not in Sun’s interest (nor that of IBM). In fact, doing so may well speed up the death of its programming language by many orders of magnitude. I postulate that as Sun squeezes its last few breaths out of Java and as more and more people enlighten themselves with much more powerful alternatives, Sun will inevtiably concede to this pressure. I declare that I have an agenda to speed up this process. Therefore, I would like to apply pressure to Sun to fix this defect so that thousands of existing software clients across the world have a smoother migration path into a more innovative and ultimately, more productive, software development environment. After all, corporations are not necessarily all about stifling innovation, are they?
As I have shown previously, the problem of partial function in Java is not easily solved. The solution of the Maybe algebraic data type, while definitely superior to existing options, is cumbersome to implement and requires some functions defined over the type (isJust, isNothing, etc.) in order to be complete. As some point out, there is a preference for continuation passing to prevent the need for a cast (even though this cast would be hidden). This prompted me to provide a more complete, yet still incomplete solution.
It is also worth noting that the solution with continuation passing will not work on the Sun VM due to its lack of tail call elimination. i.e. some concessions must be made somewhere - manual compiler optimisations if you will :) There were also some observers who didn’t quite get it. Nevertheless, many of us will go on using null/exceptions in Java or their own implementation of Maybe in Java (feel free to steal mine if you like), while others will use Haskell’s Data.Maybe, Scala’s Some/None, Nice’s option types or whatever.
All this aside, I am writing this post to introduce the Maybe Monad in Java, not to demonstrate anything meaningful or clever. Rather, I wish to simply point out to Java programmers what this abstract and apparently mystical notion of a monad - taken from the mathematical branch of category theory - really is. We now know that exceptions are only ever used for representing a partial function (even for I/O!) and we know that the Java programming language has built-in language and API support for exceptions. Let’s just revisit what the concept of a ‘partial function’ means exactly. It means that “there exists”[see note 1] some x take from our universe of discourse (U) such that f(x) is undefined.
Sound scary? It’s not really. Suppose we have a data type, int. The size of our universe of discourse is finite; it is 2^32. We can represent this as |U| = 2^32. The notation f(x) represents some function with x applied. Having a universe of discourse of finite size implies that we can do an exhaustive proof for behaviour of the function, though not necessarily in a reasonable amount of time.
Let’s call a function ‘divide’ and x can be two ints, a and b. The size of our universe of discourse of our arguments is 2^32 * 2^32 (i.e. 2 ^ 64) because that is the total number of combinations for the values of its arguments that are available. We can say that for our function, divide, it holds that for all[see note 2] a and for b = 0, the function is undefined. That is, regardless of the value of a, if the value of b is 0, the function is undefined:
int a = ... // anything
int b = 0;
divide(a, b); // undefinedIf we try to use this function with b = 0, we will observe an exception (ArithmeticException). If we were using reference types, we could write our own divide function that instead returns null or returns Maybe<Integer> and Nothing for the case of an undefined function application.
Have we got it? Great! :) The Maybe Monad is used for defining a partial function that might call 2 or more partial functions; if any of those functions called are undefined, then our function that we are writing is undefined. This might be called, “threading partial function through a computation”. We could write it in pseudo-code:
f x = if isNothing (g x)
then return Nothing
else if isNothing (h (g x))
then return Nothing
else return maybeToJust (h (g x))Very cumbersome to write and I sure hope that the function f doesn’t need to use more than 2 partial functions (g and h) in order to define! It would be great if you could write something similar to this instead…
f x = h (g x)…and not have to worry about “threading partial function through the computation”. Those familiar with Haskell, or those who are trying to understand monads in a Haskell context, should hopefully recognise the latter syntax as do-notation. Those who are not familiar with do-notation can just know that Haskell provides language support for this notion of threading computation, represented by the more familiar term, monads. This support is provided with a language keyword called do (very different to do/while in an imperative language!).
Anyway, this post is getting a bit long and I still haven’t introduced Java’s monad for threading partial function through a computation. Luckily, it is not very long to write so without further ado, I introduce it as follows:
throws“WTF!!? You mean I have been using monads all along!!? How can that be!?” Well, it has been stated more than once, that many people have already used monads, even if they didn’t call it that. In recent years, fundamental computer programming concepts have often been confused with euphemisms like “design patterns” or some such, so rather than speculate at an analogy that might be familiar, I will instead turn focus on the Java throws keyword.
Consider the following rough Java code:
T foo() throws IOException {
H handle = openFile(); // this method declares throws IOException
try {
maybeDoSomeStuff(handle); // this method declares throws IOException
// then
return someFunction(handle); // this method declares throws IOException
} finally {
close(handle); // this method declares throws IOException
}
}We see quite clearly that if any of the invoked methods are undefined then our entire method (foo) is also undefined - by returning with an exception instead of a type T. Sound familiar yet? Since we know that exceptions are only ever used to represent partial function, then we can infer that the throws keyword is indeed a (poor man’s) Maybe Monad in disguise. I note at this point that the Maybe Monad is one of a possible squillion monads that are used in every day programming; even in the weakest of programming languages. Here are a couple that are used very often though not necessarily with built-in language support:
The list monad - building up a list or threading a list through a computation
The state monad - passing “state” through a computation
The lesson from this somewhat lossy representation of a monad - that is hopefully familiar to most people - is that monads are not anything overly complicated or abstruse despite initial appearances. It requires very little brain power to digest the concept coming from a nil set of knowledge, but unfortunately, it appears to take a considerable effort if the subject has been “tainted” with ill-conceived presuppositions such as imperative programming languages.
Be assured, the lesson is brief. Be warned, the lesson is very self-confrontational.
[1] This is called existential quantification and is often denoted by the symbol ∃ [2] This is called universal quantification and is often denoted by the symbol ∀
There is quite a prolific myth that seems to have a grip on the collective software development industry. Often in communication with another software developer, the notion of a “change in requirement” will surface and I am forced to remind that developer that no such thing ever occurs - that the internalisation of this logical fallacy is in fact, quite detrimental to the purpose of creating software, fulfilling software requirements and should be abandoned. Since no such thing as a software requirement change ever occurs, the remainder of the conversation is invalidated making communication very difficult. Who’s responsibility is it to establish a sound knowledge in the fundamental concepts of their selected profession? Not mine - I am forced to cease the conversation. After all, I don’t explain to my doctor what my problem is - only my symptoms - hence, I am not a doctor. But I’ll bet doctors speak in a “language” that is beyond my capability of comprehending (though I have picked up a term or two having lived with a midwife for years :)). We software developers should be doing the same, but it does not seem to be the case.
Software is a function from some given inputs to some given outputs (a lambda if you will) and importantly, given some inputs, the same output should always result, always. It should not return some other result; it should not format your hard disk every second time and it shouldn’t cause the universe to implode or anything crazy like that - just consistently return the same value for its given inputs. This property is called referential transparency. Let’s look at a specific piece of software called ‘touch’. It takes as input:
a file system
a list of characters
It provides one output - a new file system. If a file of the given name exists on the given file system, return the new file system with that file having an updated modified time stamp, otherwise, return the new file system with an additional empty file of the given name. That’s it - nothing more to it. We might even express this software more formally as follows:
-- "Given a FileSystem,
-- then a list of characters (Char),
-- return a new FileSystem."
-- :: means 'is of type'
touch :: FileSystem -> [Char] -> FileSystem
touch fs filename = if fs `contains` filename
then fs `updateTimestamp` filename
else fs `addEmptyFile` filenameThe ‘touch’ software is so fundamental, that most reasonable operating systems provide it without any explicit user intervention - try running it and see.
While you are free to come up with all sorts of wild and complex examples of software, I’m going to simplify a little with a new example. Suppose a client approaches you, a software developer, on Monday, with the following requirement; “given two integers, sum them, multiply by 4 and give me the result.” Here is the software written in Java:
int software(int a, int b) {
return (a + b) * 4;
}Easy peasey! On a side note, write it in Haskell, then play ‘spot the difference’ with the client problem statement and the code. Fun hey? :)
If the client approaches you on Tuesday with the following, “given two integers, subtract the first from the last. multiply by 4 and give me the result.”, then it is imperative to understand that this is a new requirement. A software requirement holds from inception until the collapse of the universe. You might argue, “but the old one and the same one look almost the same”, in which case, feel free to write the second one by applying your favourite delta compression algorithm, but by no means should the former be replaced by the latter. You might also argue, “but the client said it is a change”. Well I hope my doctor doesn’t follow any advice that I give him on my condition at the time since I am not well versed in medical practice. I do not say, “I have a headache, I need to fix it with these drugs” or if I did, the doctor, being aware of my naivety, would ignore my advice and only consider the symptom (I would hope!). Likewise, clients do not project their false view of software into their final product and instead, trust the better judgment of a more trained practitioner (ideally).
If we take the common (not that I accept its legitimacy in this form) approach of unit testing and I write assert(software(42, 43) == 340), then this statement should hold forever. If it does not, then you have broken your contract to all clients of your software. The typical refutation to this assertion involves the developer ascertaining that no software clients have ever existed and so it is safe to continue. For example, if there is even a slight suspicion of a client, that developer might first deduce that if there is, then those client(s) are in the room. Then that developer asks all people in the room to commit their code so that she can search for occurrences of its use. If none are found, the software is removed, code committed and all persons in the room are instructed to update. Otherwise, if it is found that one or more clients exist, manual contingency measures are engaged.
The regularity of the occurrence of no clients bound to your software is often over-estimated. Just take a look at the mess that Microsoft has itself in with an attempt to ‘separate out the components of Windows’ or any of the other countless examples that surround us. You might say, “but I am a consultant with only one client”. This is not true; in fact, the client/provider relationship can often be self-referential. It is entirely coincidental that no clients have bound to your software, but rarely is it so.
I read an article a while back that made some claims that were oh so true. One such claim I will reproduce here because it is one that is in violation of mainstream, but portrays so much truth in so few words. I hope my reproduction is OK with the original author.
Most people I’ve met have read the Design Patterns book by the Gang of Four. Any self respecting programmer will tell you that the book is language agnostic and the patterns apply to software engineering in general, regardless of which language you use. This is a noble claim. Unfortunately it is far removed from the truth.
Doesn’t it look shiny? No polish required :) I think it would make a great wall hanging.
I have met thousands of people in my life. Of all those people, each can be described in one of four ways:
The person understands monads and would never, without duress, use an imperative programming language
The person does not understand monads, would like to and has embarked on doing so in some form
The person does not understand monads and would not like to (my doctor for example)
The person does not understand monads and in an attempt to do so, has created erroneous simplifications since “not knowing” should be defended at all costs - even if it implies the creation of a false and somewhat convenient reality
I implore any person not to fall into the latter category, but I do understand that this imploration is based on my value system, which has a strong emphasis on the philosophy of epistemology. If the phrase, “ignorance is bliss” (without the negative connotation), is valuable to you, then so be it. I am also very keen to know of any persons who cannot be described this way, but to date, I have found none.
My school friends were sad when they found out that Santa Claus was not real - I was angry.
If you live in Australia and you own a television, you’ll likely be aware of the retirement of Ian Thorpe - one of our best swimmers. As per usual for the media, the coverage of “Thorpy’s” retirement is disproportionate to the event and no doubt we (Australians) will be hearing about it for days to come, with follow ups of course. Personally, I do not enjoy watching swimming, regardless of the speed of the “fish” at hand - I find it boring, though I do admire the athleticism, training and dedication of its participants.
While Thorpe’s achievements in swimming should not be undermined, I turn attention to a sport that over the last couple of decades has lost the spotlight with respect to the media and remind Australians of some of our other courageous sports-persons. I hope Thorpey is grateful for my attempted diversion :) It must be horrible having a live and detailed personal profile plastered nation-wide.
David Palmer is an Australian who has held the world number 2 - repeat, world number 2 - position on the Professional Squash Association rankings list for almost all of 2006. I say “almost” because he achieved world number 1 in February and world number 4 in January. While his profile is not as high as our beloved Thorpe, he is just as strong an athlete and being a competition squash player myself, I have a personal admiration for the skill of players at his level, since they are skills that I aspire to.
If we take a look at the PSA World Rankings, we also note some other Australians; Anthony Ricketts, Stewart Boswell and Cameron Pilley, all of which I watch with awe as they perform on a squash court. If we turn our attention then to women, we have the two “Grinham sisters” within the top 5 and some rising Australian stars following on the WISPA World Rankings.
As Australia becomes the 52nd state of America (culturally and politically), we lose some of our tradition and along with it, our love of the sport of squash - Americans have a negative stigma attached to squash as they generally prefer racquetball, though I believe or at least, hope, that this is changing with some “education” i.e. Trying It And Seeing. You’ll note many British and Middle-Easterners on the world rankings list. Nevertheless, Australians need to be reminded of some of our equally talented athletes in other disciplines besides “getting from one end of the pool to the other as quick as you can”.
Cheers to Thorpey.
I posted the link to Maybe in Java to programming.reddit.com and waited a good… hour or so, before giving up and going to bed. Actually, I happened to lose interest in posting it and by-chance, noticed my web browser still hadn’t completed the request on the way to bed. Nevertheless, it seems my HTTP request managed to make it there and when I woke up the next morning, there were all sorts of comments floating around. A few in particular asking something along the lines of, “what exactly has been achieved?”.
I will answer this question with “I have pointed out to Java programmers the concept of a very basic algebraic data type and importantly, in their language”. No mathematics, no type theory, nothing that will scare away your average J2EE Joey Jumper. I have also made a subliminal point of “hey! there are languages that already do this, only better!”. In particular, I have not provided anything that you should all go out and start using on your next WebSphere-fronted, RDBMS-backed, one-trillion-gazillion LOC web application. It seems the following points were missed in my original writing:
Throwing an exception is one of our possible options for evaluation of a partial function in Java. Here are all our options available in Java: … Emulate continuation passing style (CPS)
data Maybe a = Just a | Nothing (the Haskell equivalent i.e. omitting instances)
I’ll let your imagination run wild with possibilities from here :)
To remedy this situation, I have added further to the original Maybe type which was intentionally left incomplete, and it is still not complete. I hope this will help those who haven’t made the leap to do so and those who have made the leap, to understand my objective in this writing.
public abstract class Maybe<t> {
private Maybe() {
}
public abstract <q> Q maybe(JustC<Q, T> jc, NothingC<q> nc);
public static abstract class Nothing<t> extends Maybe<t> {
private Nothing() {
}
}
public static abstract class Just<t> extends Maybe<t> {
private Just() {
}
public abstract T just();
}
public static <r> Maybe<r> _just(final R r) {
return new Just<r>() {
@Override
public R just() {
return r;
}
@Override
public <q> Q maybe(final JustC<Q, R> jc, final NothingC<q> nc) {
return jc.c(r);
}
};
}
public static <r> Maybe<r> _nothing() {
return new Nothing<r>() {
@Override
public <q> Q maybe(final JustC<Q, R> jc, final NothingC<q> nc) {
return nc.c();
}
};
}
}
public interface JustC<Q, R> {
Q c(R r);
}
public interface NothingC<q> {
Q c();
}Those of you familiar with the Visitor Design Pattern (or any other GoF design euphemism) will immediately recognise the modification - hence the title of the post :). Please feel free to replace identifiers with your preferred view of the world; continuation, quasi-continuation, visitor, whatever.
For those who insist on returning null or throwing an exception/error, or more so, insist on failing to recognise the distinction, I have yielded to your pressure:
public final class NullNothingC<t> implements NothingC<t> {
public T c() {
return null;
}
}
public final class ErrorNothingC<t> implements NothingC<t> {
public T c() {
throw new Error();
}
}In Haskell, there is an algebraic data type called Maybe to represent evaluation of a partial function. That is, if you have a function, say f(x), and f(x) is defined for some x, but not all x, you return either:
A type Maybe that has a value available - called Just a where a is the value - representing defined function evaluation.
A type Maybe that has no value available - called Nothing - representing undefined function evaluation.
In fact, if we were to look at the source for the Maybe algebraic data type in GHC, we’d see this:
data Maybe a = Just a | Nothing
Not much to it, eh!? This Haskell snippet can be read as “Declare type Maybe with one polymorphic unbound variable ‘a’ that can be constructed as either Just ‘a’ or Nothing”.
Consider a real Java example, List.get(int index), which returns a type T where T is a type parameter (it once returned type Object prior to 1.5). For some Lists and some ints, this function is undefined. For example, for the list [1,2,3] and the int 7, List.get is undefined. In fact, this will throw an IndexOutOfBoundsException if attempted:
java.util.Arrays.asList(new Integer[]{1, 2, 3}).get(7);
Throwing an exception is one of our possible options for evaluation of a partial function in Java. Here are all our options available in Java:
Return null
Throw a compile-time checked exception
Throw an unchecked exception
Emulate continuation passing style (CPS)
I have distinguished checked and unchecked exceptions for a specific reason that I’ll leave for another day and I won’t go into great detail about any of these options in specific, since I am currently in the middle of documenting all this in more detail along with some basic type theory. However I will note that each of these options for evaluation of a partial function have some kind of nasty consequence. For example, the value null is assignable to any reference type and so can inadvertently be passed along to a method (I am sure you have seen this before):
T t = f(x);
// is t null?
// the compiler doesn't force us to check!
// how does the method behave now?
method(t);And how long has that checked/unchecked exception debate been going? Yes there is a reason it has been going for so long - in fact, it is riding on a flawed premise so it will continue on forever until its participants realise this flaw - but we’ll leave that for another day and smile and nod in the meantime. :)
With a Maybe data type, we might instead write our function/method as:
Maybe List.get(int index)
…where undefined behaviour is denoted by returning Nothing and defined behaviour is denoted with Just T. We should also be assured that only one of these two things will occur. No more returning null, no more throwing exceptions!! How wonderful would that be!? Well, if you’ve ever dabbled in Haskell or type theory, you’ll know immediately how great that would be - but what about Java?
An initial and naive attempt to emulate Maybe fails immediately:
interface Maybe<t> {
T get();
}We see that we have isolated our apparent anomaly that we are trying to resolve. We must still either return null or throw an exception from the Maybe.get method, but no other method ever need do so - as long as we (hopefully) remember to check for null for any given Maybe. While a slight improvement, this of course, does not solve our problem. We are still returning null or throwing exceptions and importantly, suffering the adverse consequences of doing so (we want the compiler to fail, not have to remember to do stuff!). Instead, we need to use types to represent Just and Nothing. Let’s try another attempt.
interface Maybe<t> {
}
interface Just<t> extends Maybe<t> {
T get();
}
interface Nothing<t> extends Maybe<t> {
}Done!! Or not. There is a specific guarantee that our Haskell data type makes that our Java attempt doesn’t. Specifically, if a Maybe is not Just, then it is definitely Nothing and vice versa in Haskell - this is important if we are to continue. We can see that this constraint does not hold for our Java Maybe because it can have any number of sub-types - of course - since it is an interface. We know how to constrain a type to have zero sub-types; by using a class with the final keyword. We know how to free a type to have infinite sub-types; without the final keyword or an interface. But what about constraining a type to 2 and only 2 sub-types?
This can be achieved by exploiting a little known Java language feature - a type cannot be sub-typed if it has only private constructors unless those sub-types are nested in the super-type. It seems we can indeed have a Maybe algebraic data type in Java by having 2 and only 2 sub-types!
public abstract class Maybe<t> {
private Maybe() {
}
public static abstract class Nothing<t> extends Maybe<t> {
private Nothing() {
}
}
public static abstract class Just<t> extends Maybe<t> {
private Just() {
}
public abstract T just();
}
}Looking good so far. We now know for sure that every instance of Maybe is either Just or Nothing and if it is Just, we have a value available through the get method - exactly what we ordered. As it stands though, we cannot create instances - let’s expose these through public methods.
public abstract class Maybe<t> {
private Maybe() {
}
public static abstract class Nothing<t> extends Maybe<t> {
private Nothing() {
}
}
public static abstract class Just<t> extends Maybe<t> {
private Just() {
}
public abstract T just();
}
public static <t> Maybe<t> _just(final T t) {
return new Just<t>() {
public T just() {
return t;
}
};
}
public static <t> Maybe<t> _nothing() {
return new Nothing<t>() {
};
}
}And so there we have it - an algebraic data type in Java for evaluation of a partial function. How does our List method look now? How about this:
Maybe List.get(int index)
Clients of this method will now check if the return type is either Just or Nothing and in the case of Just, perform a downcast and retrieve the value. No more returning null. No more throwing exceptions. Not ever!
I’ll let your imagination run wild with possibilities from here :)
As I have mentioned, I plan to go into greater detail about this problem by documenting it in detail so keep an eye out on the Workingmouse Research page.
Until then, I’ll keep you wondering will a small piece of interesting code:
import java.util.List;
import java.util.LinkedList;
import java.util.Map;
import java.util.Hashtable;
class ListMap {
public static void main(String[] args) {
Map<Integer, String> map =
new Hashtable<Integer, String>();
map.put(0, "x");
map.put(1, "y");
map.put(2, "z");
List<string> list =
new LinkedList<string>();
list.add(0, "x");
list.add(1, "y");
list.add(2, "z");
// xyz
System.out.println(map.get(0) + map.get(1) + map.get(2));
// xyz
System.out.println(list.get(0) + list.get(1) + list.get(2));
// returns null
System.out.println(map.get(7));
// throws IndexOutOfBoundsException
System.out.println(list.get(7));
}
}After surviving day 1 of the Fourth ASIAN Symposium on Programming Languages and Systems, I have to say it is refreshing to be reminded of how much academic work is being put into providing solutions to the diverse set of software problems that exist today. I use the term “surviving” to annotate my lack of coherence as a result of attending the U2 Vertigo concert in Brisbane the night before and having received a total of 90 minutes sleep (0230-0400) before heading to the airport bound for Sydney on a 0530 (GMT +1000) flight. Since my spatial ability is generally proportional to the quality of my sleep, I have had to memorise much of the latter part of day 1 of APLAS ’06 - ready for processing at a later date - batch processing if you will :)
There were some excellent presentations - all of extremely high quality - and more than expected in my specific areas of interest. There seemed to also be a pre-requisite understanding of the Haskell programming language and much of the theory behind it, which was also great to see, since it allowed some presentations to go into great detail about various topics. The invited presentation scheduled for 0930 (GMT +11) was given by Professor Peter Stuckey titled, Type Processing by Constraint Reasoning. It is in this talk that I learned of a project titled, Chameleon, which goes about providing a rich set of information for type errors. Professor Stuckey also seemed to highlight the common misunderstanding that comes with a type error as being interpreted as “something is wrong” with the correction “at least one of two things went wrong, since you have at least one contradiction that cannot be resolved” - at least, this is my translation of his emphasis. I think this distinction is extremely important and I applaud anyone who sets about making it. I won’t continue paraphrasing what appears to be a massive amount of work in understanding and then implementing an artifact of Type Theory, so if you have a chance, I encourage anyone to take a look at the paper.
It is also during this presentation that I learned of Helium for teaching Haskell to beginners. I have yet to take a detailed peek at Helium, but since I have an interest in teaching at the tertiary level as well as “weaning people of the mainstream guff”, I have hopes that Helium can be an extremely useful tool in achieving my objectives.
You’re working away on your Java (or .NET for that matter) project and you want to redefine the equality for some type; let’s say, for a String. The new requirement mandates that two Strings are “equal” as per usual except that if they have a length greater than or equal to 3, then it is only the first 3 characters that need to be equal for the Strings to be equal. For example:
“abcdef” and “abcxyz” are equal
“abc” and “abcdef” are equal
“ab” and “abc” are not equal
“ab” and “ab” are equal
“” and “a” are not equal
“” and “” are equal
Make sense so far? Good! :) If our problem was related to the ordering of instances of our type, we already have Comparator in the core API to cater for this scenario and best of all, the collections supports the use of our comparing strategy e.g. we can pass an instance to the constructor of TreeSet. However, our problem is related to testing for equality, not ordering. How would the analogous Comparator interface look for equality? How about this:
interface Equalable<t> {
boolean isEqual(T t1, T t2);
}It’s too bad the collections don’t support this type, ain’t it? We can’t plug in our own strategy for testing for equality like we can for comparing for order if we intend on using collections. Instead, the only way we can meet our requirement and still use collections (or anything that uses the inherent equals method) is by declaring a new type:
public final class XString
{
private final String str;
public XString(final String str) {
this.str = str;
}
public String getStr() {
return str;
}
public boolean equals(final Object o) {
...
}
}Now we can have collections of this type as it defines its own equality test strategy in accordance with our original requirement. What if the collection types allowed you to pass an instance of Equalable instead? Much easier than having to write our XString type!? Instead of having to create the XString type, we might be creating HashSet instances like so new HashSet(new MyEqualable()); and be done.
Let’s take a look at how this would look in another programming language - with Haskell - a purely functional programming language. In Haskell, we have the same two choices, we might implement the type-class Eq or we might pass a first-class function of type a -> a -> Bool
newtype XString = XString String
instance Eq XString where
...Now, if we had a function of type a -> b [see note 1] and that function needed a strategy for equality over the type a to evaluate, we have two choices:
we could bound the parameter by the Eq type-class, which would look like so as a function definition Eq a => a -> b and reads as “takes an argument of type a, where a is bound by the type-class Eq, and evaluates to an unbound type b”
we could leave the parameter a unbound and pass a function as an argument. This function would be of type (a -> a -> Bool) and would define the strategy for determining if two a’s are equal. Thus our entire function definition would look like so (a -> a -> Bool) -> a -> b where we see that a is not bound by any type-class i.e. it is unbound.
Back into Java land… these two options in Haskell can be likened to java.lang.Comparable and java.util.Comparator. Suppose now you have a reference of type Set and you wish to call an existing method of type m(Set). It is only sensible that you are able to call this method, since (let’s assume) it has nothing at all to do with the only differentiator between the two types - the strategy for determining equality. Gotta write a new type right?
Now, since this is my first blog post ever, I reserve the right to throw out some incredibly bold and apparently absurd postulations :). Since such a simple requirement mandates the creation of so much code to fulfill accurately, I postulate, with more formal reasons forthcoming, that approximately 99.9999% of the content of the J2SE API Specification [see note 2] is a result of this problem that is inherent in a language such as Java with a substandard type system. I might name this problem, “Gotta write a new type, right?” for future reference and just to take the piss out of the dominant programming language(s) of our evolving [see note 3] industry. So that’s its name, OK? Great.
I do not envy you oh Senior J2EE Architect/.NET Super-duper Spanky Star (what do they call those anyway?).
[1] This can be read as “takes an argument of type a and evaluates to a type b where a and b are both polymorphic and unbound”. The analogous Java is:
interface I<a, b> {
b f(a arg);
}[2] The “thing” (monolithic abominable creature?) that I used to laboriously implement for IBM http://java.sun.com/j2se/1.5.0/docs/api/
[3] I must have backspaced 50 or so times before finally settling on the conservative adjective, “evolving” :)