4th August 2010, 02:22 pm

There a belief about Haskell that keeps popping up in chat rooms and mailing lists — one that I’ve been puzzling over for a while.
One expression of the belief is “everything is a function” in Haskell.

Of course, there are all of these non-functions that need to be accounted for, including integers, booleans, tuples, and lists.
What about them?
A recurring answer is that such things are “functions of no arguments” or functions of a one-element type or “constant functions”.

I wonder about how beliefs form, spread, and solidify, and so I asked around about how people came to this notion and how they managed to hold onto it.
I had a few conjectures in mind, which I kept to myself to avoid biasing people’s responses.
Of the responses I got, some were as I’d imagined, and some were quite surprising to me, revealing some of my blind spots about others’ thinking and about conversation dynamics.

My thanks to the many Haskellers, especially newbies, who took the time to help me understand their thought processes.
If you’re interested and in a patient mood, you can see the unedited responses on a Haskell reddit thread and on a #haskell IRC log.
There were also a few responses on Twitter.

**Edits:**

- 2009-08-04: Added “simplify”: “Would making everything a function really simplify the formal system that is Haskell programming?”. Thanks, SLi.
- 2009-08-04: Focus on “constant function” story for “It makes things simpler”. I realized that I hadn’t said what I intended there. Thanks, Jonathan Cast.
- 2011-03-04: Remarks on mutability & dynamic typing, under “Operational thinking”

Continue reading ‘“Everything is a function” in Haskell?’ »

There a belief about Haskell that keeps popping up in chat rooms and mailing lists -- one that I've been puzzling over for a while.
One expression of the belief is "everything is a function" in Haskell.
Of course, there are all of these non-functions that need to be accounted for, including integers, booleans, tuples, and ...

2nd August 2010, 05:58 pm

Functional programming abounds with recursively defined data types.
We often draw these structured values as trees with the root at the top and the leaves at the bottom.
*Lazy* functional programming allows values (structures) of these types to be “bottomless”, meaning we can descend forever.
There are many examples of how supporting such values gives an enormous boost to modularity.
(See, e.g., John Hughes’s classic paper *Why Functional Programming Matters*.)
We usually refer to these values as “infinite”, but I’d like to suggest “bottomless” as a more specific alternative, and to point out a limitation that perhaps is not widely noticed.

Although we can *descend* infinitely in lazy functional programming, we can only *ascend* finitely.
If I’m traversing a lazy list, there may be infinitely many elements on my right (yet to be visited) but only finitely many on my left (already visited).
While traversing a tree, there may be infinite paths below but only a finite one above (leading to my current position).

In other words, our data is bottomless, but not topless.
What would it be like to go beyond our usual merely *uni-infinite* data and program with *bi-infinite* data instead?
With data that is both bottomless and topless?

Continue reading ‘Topless data’ »

: http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html "Paper by John Hughes"
: http://conal.net/blog/tag/memoization/ "Posts on memoization"
: http://conal.net/blog/posts/another-angle-on-zippers/ "blog post"
: http://conal.net/Pan "project web page"
: http://conal.net/Pajama "project web page"
: http://conal.net/blog/posts/exact-numeric-integration/ "blog post"
: http://hackage.haskell.org/package/Stream "Haskell package: Stream"
: http://conal.net/blog/posts/sequences-segments-and-signals/ "blog post"
: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.83.8567 "paper by Mitchell Wand"
Functional programming abounds with ...