# Applications

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

```      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
`(1,4)`
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
`xs_fst`
and
`xs_snd`
. Hmm... well, let's take a more trivial but nonetheless non-trivial case:
```      unzip [(1,4)] = ([1], [4])
```
Now in this case, what do
`xs_fst`
and
`xs_snd`
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)
where
(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 ::

## Suggested HApps examples

Submitted by metaperl on Wed, 11/29/2006 - 9:22am.

Happs is a great web kit for haskell, but a a recent thread in the mailing list shows that it needs examples. Here is a good set of starters:

example1: the simple one-liner that serves static files
(with example static files to serve)

example2: adds to example 1 some simple state
(for example a counter)

example3: adds a request handler that displays
a dynamically-generated page that
displays the state

example4: adds an input and a handler that can
be used to change the state

...and so on, for savers, sessions, etc.

Each example would reuse the code from the previous one, so that notes
could highlight the changes, and explain their motivation.

-- credit to Mikel Evins for the example list

## Python Decorators - not desirable in Haskell

Submitted by metaperl on Wed, 11/29/2006 - 2:08am.

This is not a planned out post, but I feel the need to compare Python decorators with The Haskell Way.

I recently read Philip J. Eby's article on decorators and it was eye-opening.
Let's see first what the purpose and definition of a Python decorator is before comparing them with The Haskell Way.

PURPOSE
Philip says that one use of decorators is to reduce code duplication. For example if a set of methods needs to be wrapped for additional functionality, such as synchronization, pre/post conditions, etc, then you can simply annotate each with the appropriate decorators.

The second use is to have the meta-information about functions right with the function so that the data is never out of sync with the function. Then you can locate all methods with certain characteristics via the decorator API (I suppose)

DEFINITION

I don't know why it took Phillip to the middle of the paper to define a decorator, but I think it was a good move... to sort of whet your appetite before giving you the definition. After all, this is not a mathematical proof. Anyway, a decorator is "...a callable object (like a function) that accepts one argument—the function being decorated. The return value of the decorator replaces the original function definition."

The very first thing that comes to mind is decorating destroys manifest interface. You can no longer examine a piece of code and examine the type signature of the functions it calls and know what is supposed to happen.

Haskell employs an entirely different approach to modifying function behavior. If you have a stereotyped way of modifying a set of functions, you would have to call the modifying function not call the original decorated function.

This is actually more flexible and composeable - the original function does one thing simply and clearly, then any combination of control strategies can be layered on top via other functions.

Let's take each of Philip's purported purposes of Python Decorators and see how Haskell accomplishes the same thing, but with that unmatched Haskell-esque elegance, flair, power and control. Yes, that's right, all 4 terms apply: elegance, flair, power and control:

CODE DUPLICATION
Well, that's what functions are for. If there is a list of things that need to be done to a function, then that itself is another function taking the first function as an argument.

The additional power of The Haskell Way is that you are not tied down to decorating a single function in a single way... for example: is it really the case that you should be decorating the division of two numbers with an exception? What happens when you want to decorate it with something to generate HTML instead?

SCATTTERING OF KNOWLEDGE
Phillip says that sometimes "...a framework needs to be able to locate all of a program's functions or methods that have a particular characteristic, such as 'all of the remote methods accessible to users with authorization X.'"

But I dont know about that. When was the last time I needed this sort of information? If so, is seat-of-the-pants annotation the way go? Why not use Template haskell to generate all such methods ahead of time?

CONCLUSION

Decorators do not belong in Haskell. They rob a language of referential transparency. They result in "pull-style" programming as opposed to injecting control.

## Tools for haskell problem solving

Submitted by metaperl on Tue, 11/28/2006 - 6:43pm.

TYPING
This is your very first tool. Write out the type for the function that will solve your problem.

CASES
Write down your trivial base cases

INDUCTION STEP
You wrote down your accurate base case. Now imagine your function having to process an input data set with just one element more than your base case.

Then, write out that case algebraically

PICTURES OF DATA FLOW
Cale Gibbard has some nice pictures of how data can flow through functions when using foldl. And the technique is applicable elsewhere.

## One job title you will never see - Junior Haskell Developer

Submitted by metaperl on Thu, 11/23/2006 - 2:19pm.

I am a Senior-level Perl developer with 6 years of corporate experience.

I managed to eek my way to this lofty status by imitation. I bought lots and lots of Perl journals, read lots and lots of code, chatted in IRC channels, read perlmonks.org religiously and basically became capable of aping an answer to anythiing at anytime.

Oh and CPAN modules helped a lot because I only needed to follow directions and they cover almost any corporate scenario one might have.

So, at one time I was a junior sponge and now I am a senior sponge. I am not more intelligent I just have more idioms under my belt and can crack them off almost unconsciously.

Flip to Haskell. I have tried this approach to learning Haskell 2 or 3 times and each time I had to call the paramedics for oxygen. There is no such thing as a Junior Haskell Programmer.

You either possess the ability to conceptualize the functional decomposition of a problem or you get NOTHING done.

Haskell is a very exacting discipline and you either Master it or remain a fool and the only difference between the two is how much time you put into gaining a grasp on the power, scope, elegance and techniques for wielding the 3-fold synergy of strong typing, lazy evaluation, and purely functional application.

As a side note, I am of course wise enough to be dropping Perl for Python. And even though it is not Haskell, it is worlds better for 90 million reasons I wont go into right now.

## Research idea - mapping haskell type signatures to real world questions

Submitted by metaperl on Tue, 11/21/2006 - 5:08pm.

Hoogle is sort of what I'm thinking about. But Hoggle requires well-typed info to find the functions you are looking for. And hoogle does not string together functions into solutions or programs.

In #haskell, all day long, there is question after question such as "How can I get a list of all pairs from this list" or "how do I apply a function to the first element of a list and then take that result and apply it to the next element of the list?"

Can we take the next step from hoogle and take english language requests and turn that into haskell code?

Can we build a browser for Haskell functions that allows one to navigate a tree of semantic concepts?

Most importantly, can we get inside the head of a Haskell programmer and break down his solutions into easy steps to make it easier for others to learn haskell?

## Any need for a Python interface to Haskell?

Submitted by metaperl on Tue, 11/21/2006 - 3:57pm.

John Goerzen has created
a Haskell interface to Python and done a bang-up job.

However, it does not look like anyone has made Haskell available to Python.

I did get better search results using
Windows Live rather than Google. Thanks to Windows Live, I found epolyglot which employs Haskell Direct and demonstrates a possible route

## Python - Haskell comparison: delete all files matching *m3u

Submitted by metaperl on Fri, 11/03/2006 - 5:24am.

Python is a not-bad language... much nicer than Perl. Not as rigid as Haskell. Many more libraries and applications than Haskell. And Python was used in this years winning ICFP as well. And Python stole list comprehensions for Python. And PYthon combined object, functional and imperative in a prettier more understandable way than Ocaml did.

Here is a script I whipped up in Python to remove all m3u files from my music dir... the shell 1-liner of

``` find ~/Music -name '*m3u' | xargs rm ```

failed because find did not properly escape spaces and parentheses.

So here's my script:

``` #!/usr/bin/env python```

``` from path import path p = path('/Users/tbrannon/Music') print p dirs = p.walkdirs('*') print dirs for d in dirs: for f in d.files('*m3u'): print f f.remove() ```

What would the Haskell look like?

## Languages for ICFP 2006 posted --- C++ wins? or Haskell

Submitted by metaperl on Wed, 10/18/2006 - 7:03am.

If you look at the winning team's language list:
http://www.boundvariable.org/teams.shtml#1346

they listed C++ first. and Haskell second.