metaperl's blog

Memorable quotes

Submitted by metaperl on Fri, 12/08/2006 - 1:19am.

This is a placeholder thread for all of the funny things I see in #haskell


one of the reasons oo is so good at solving problems is because it's so good at creating them :)

Daydreaming about teaching haskell

Submitted by metaperl on Thu, 12/07/2006 - 8:40am.

"Ok students, today we are going to learn something different and amazing. It's called purely functional programming... did you notice you entered this room? Sometimes 1 of you came in, other times 3 came through the door? Well, in a functional language, that would be OK, but we would type it like this:

enterDoor :: timeQuanta -> [Student] -> [Student]


I started this out as a post about how a function always took the exact same arguments... ALWAYS... OK now I got it.

"Ok students, you noticed you that dog came in? And then that principle? That's the beauty of FP. Any possible set of inputs MUST be stated up front, so we have to change our funciton again."

Hmm, this didn't go as planned but it's leading somewhere. Bear with me. I'll clean this up sometime... i'm supposed to be working now :)

The Haskell type system bothers me

Submitted by metaperl on Thu, 12/07/2006 - 4:58am.

A type is a set of values. Earlier, I discussed how I had to do programming on something that was no more than a list whose elements were "consed" together via carriage returns:

"item 1\nitem2\nitem 3"

While I did manage to write an implementation of lines, the Haskell type system is reknowned for forcing programmers to describe their data up front.

But, the Haskell type system did not interpret my string as a list for me.

I think Cale said it best recently

Sometimes the static typing language just doesn't have the types necessary to express the conditions on code which the programmer would want to express, and sometimes adding those additional types will either spoil type-inference, or make the problem of proving that a program satisfies its types much harder, or even make it outright impossible for the compiler to do for itself.

In reflection, I suppose I could resort to Parsec to produce a list for me.

Musing about very strong types and their accessors

Submitted by metaperl on Mon, 12/04/2006 - 2:40pm.

In working through SJT, I was required to implement lines. For the first time ever, I managed to break a Haskell program while running it instead of the type checker catching the problem. Feast your eyes on this:

*Main> mylines ts
["dog","cat"*** Exception: Prelude.tail: empty list

As usual, that got me thinking about how I got into the situation. And it hit me, that my main problem is that I had to do programming instead of creating a very strong type and related accessors.

In other words, lines converts a sequence of lines into a the sequence we call a list.

It seems that I should be able to type a string consisting of carriage return delimeters as a lazy list which returns elements.

Hmm, just brainstorming.

Haskell Project List

Submitted by metaperl on Sun, 12/03/2006 - 8:28am.

Here I list everything that I will probably never get the time to do, but want to do.

haskell paste site has gone down one too many times for me. I think it's time we had our own robust paste tied into lambdabot.

Please dont sweat the small stuff

Submitted by metaperl on Fri, 12/01/2006 - 3:11pm.

I am happy that I finished Chapter 7 of SJT today. It was a mammoth chapter. It involved a lot of thinking and I am a stronger programmer for having made it.

That being said, I really needed to fight my addiction to perfection. On a hard exercise, I took the liberty of stringing together several prelude functions without (a) learning how they worked or (b) rewriting them myself.

Also, my solutions may not be the most efficient.

But you know what? I'm done with the chapter and I'm better.

If I really wanted to be anal, I would have to rebuild the hardware I'm on for max speed. And then recompile ghc with all the right compiler flags, etc, etc.


I'm at a crossroads in my Haskell study

Submitted by metaperl on Thu, 11/30/2006 - 11:21am.

Chapter 7 in SJT is "Defining functions over lists" --- this is arguably the meat-and-potatoes chapter of the entire book, and it has some great exercises.

However, I was a bit concerned with the given implementation of split because it went over the same part of the list twice:

split :: String -> [Word]
split [] = []
split st
  = (getWord st) : split (dropSpace (dropWord st))
which lead me to examining the source in the Haskell prelude

It looks interesting. So I'm pondering whether to study the entire prelude or continue on with the text.

I think the book is better for me, so that I can learn more of the Haskell system - modules, type classes, infinite lists, monads, algorithm analysis.

It will make me a complete programmer, ready for other interesting articles and exercises and contributions to the Haskell community.

A very nice short monad tutorial

Submitted by metaperl on Thu, 11/30/2006 - 3:17am.

exists right here
... I like how he partitioned the idea of monads into 3 types. I wonder why Cale wrote "Monads as Containers"... was he trying to say that was the only way to look at them? Or must a container always be present? I'll have to ping him on that.

Metacognitive processes involved in deriving a solution to unzip

Submitted by metaperl on Wed, 11/29/2006 - 1:10pm.
Writing my own implementation of unzip was difficult.

This morning I began to think that working top-down was not the best idea. Or perhaps that working both top-down and bottom-up is best... let's see.

First, let's apply our every-useful top-down tools for problem solving - typing, cases, pictures and induction step.

Let's start with typing unzip:

      unzip :: [(a, b)] -> ([a], [b])
Ok, great, so we are getting in a list of 2-tuples and want to convert that into a 2-tuple in each element tuple element is a list. Let's continue with some easy cases:
      unzip [] = ([].[])
Ok, how about a picture of a non-trivial case:
      unzip [(1,4),(2,5),(3,6)] = ([1,2,3], [4,5,6])
Hmm, the first thing that I see is the tuple
has been broken out into the first elements of the output list. Let's give an algebraic expression of that:
      unzip (x:xs) = ( fst x : xs_fst , snd x : xs_snd )
Cool, I love it! Now we only need specify how to get
. Hmm... well, let's take a more trivial but nonetheless non-trivial case:
      unzip [(1,4)] = ([1], [4])
Now in this case, what do
look like? That's right, they are empty lists, which means our trivial case applies. In other words, in this case:
      (xs_fst, xs_snd) = unzip([])
Which means:
      unzip [(1,4)]    = (1 : xs_fst, 4 : xs_snd)      
           (xs_fst, xs_snd) = unzip xs -- Since xs == []

an entirely different approach

Lock in the base case

      unzip [] = ([].[])

Rewrite your type signature using the base case whenever possible

Sounds odd, but let's do it:
      unzip :: [(a, b)] -> ([a], [b])
      unzip [(a, b)] = ([a], [b])   -- this is true for a 1-elem input list
      unzip  (a, b) : []  = (a : [], b : []) -- rewrite in cons notation
      unzip ((a, b) : xs) = (a : a', b : b') -- this generally true! done!
        where (a', b') = unzip xs

The only reality is the present moment - state retention is delusion

Submitted by metaperl on Wed, 11/29/2006 - 10:52am.

I do quite a bit of spiritual search in my freetime. And for the longest, I have been bitten by this idea over and over, so now I will express it. And this is not my idea, you can read Eckhart Tolle, "The Power of NOW" or listen to any Advaita Vedanta teacher and they will tell you:

the only thing that is real is the present moment.

your thoughts about the present moment are attempts to conceptualize and relate this moment to other stored concepts and relations. This is what is known as understanding. It is not knowledge, but rather mental comprehension.

Also, Repeatings and recordings via memory are only real when they are brought into the present moment. all of Which means everything which ever happened and everything that ever will happen will happen in the NOW.

So what? Well, Haskell, being a purely functional language is all about NOW. It is one of the few languages which makes a concerted effort to have all statements about past and future effects cleanly, correctly and completely and explicitly described from the standpoint of the Ever Present Presence.

:: steps down from soapbox ::