λ Tony’s blog λ

<<< Insert thoughtless commentary about Scala here. Be sure not to forget that emphatic display of spectacular ignorance of the subject at hand. Click here to solicit peer support in the event that you begin to consider the possibility that you do not understand elementary topics of computer programming. Keep that hyperbole hyperbolin’! >>>

L4/L5/S1/Sacro-iliac fusion

• 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.

Manuel M T Chakravarty — University of New South Wales

Brisbane Functional Programming Group

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.

2. Option.getOrElse

Java 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:

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.