Future values

A future value (or simply “future”) is a value that might not be knowable until a later time, such as “the value of the next key you press”, or “the value of LambdaPix stock at noon next Monday” (both from the time you first read this sentence), or “how many tries it will take me to blow out all the candles on my next birthday cake”. Unlike an imperative computation, each future has a unique value — although you probably cannot yet know what that value is. I’ve implemented this notion of futures as part of a library Reactive.

Edits:

  • 2008-04-04: tweaked tag; removed first section heading.

Continue reading ‘Future values’ »

Switching blog engines

I gave up on Blogger, where I’d been keeping my technical blog. Blogger was removing one leading space per line of pre-formatted html (“code”) on every edit/preview cycle.

Meanwhile, I’ve been enjoying using Markdown, so I poked aroud and found a WordPress solution I think I’ll like for a while. You’re looking at it.

The steps are described in a post on Syntax highlighting with Markdown in WordPress. It uses a combination of PHP Markdown Extra and GeSHi (Generic Syntax Highlighter), plus a small extension to specify which language for a block of code. It works great. I tweaked the PHP code to make the default language be Haskell instead of txt. The GeSHi-decorated code even has links to library documentation, which I love.

I had a bit of trouble along the way and got help on the #wordpress IRC channel. It turned out that I hadn’t followed the installation directions for PHP Markdown Extra, which say to move markdown.php out of its directory directly into my plugins directory. Once I knew to look in the Apache error log, it was pretty easy to track down the problem.

Still to do:

  • Work out how to automatically add documentation links to GeSHi. For now, I’ve manually added Data.Monoid, Control.Applicative, and Control.Arrow.
  • When I want to go public, get Haskell Planet to point to the new blog.

Blogging and formatted code

I’d like to hear from anyone who is happy with their blogging engine’s treatment of code. I use Blogger, and it strips leading spaces from each line of my code on every edit/preview pass. I lose alignment, and eventually, all the code ends up at the left margin.

Tangible Functional Programming: a modern marriage of usability and composability

Earlier this month I gave a tech talk at Google, entitled “Tangible Functional Programming: a modern marriage of usability and composability”. Thanks to Google folks, the talk is now up on YouTube. I showed a way make functional programming “tangible” and visual, rather than abstract and syntactic and, in doing so, to fulfill the original Unix vision of simple, composable apps.

The key is to keep an app’s interface and functionality combined and separable. Combined yields usability, and separable yields composability. This principle applies not only to GUI-style interfaces, but to textual IO as well, and it applies to both direct composition and syntactic composition. See the TV page for examples of the latter. The common practice of mixing IO with functionality inhibits composability whether in C or in Haskell.

Edits:

“Tangible Functional Programming” — icfp version

I just submitted the camera-ready version of “Tangible Functional Programming”, for ICFP ’07. I’m happy with this version. It’s improved drastically since my first submission to ICFP ’06, thanks to many helpful comments. I’ve also been recreating the implementation on top of DeepArrow, Phooey, and TV, in preparation for a software release. It’s getting simpler, but it’s not as simple as I want.

Implementing a type for partial values

A type for partial values

In simplifying my Eros implementation, I came across a use for a type that represents partial information about values. I came up with a very simple implementation, though perhaps not quite ideal. In this post, I’ll present the interface and invite ideas for implementation. In the next post, I’ll give the implementation I use.

Continue reading ‘A type for partial values’ »

Paper draft: “Applicative Data-Driven Computation”

I would love to get comments on a short (4.5 page) paper draft called “Applicative Data-Driven Computation” (Haskell wiki page), which describes a very simple approach to data-driven (push-based) computation and its application to GUI programming. There’s a “Talk page” link for discussion.

I’m also very interested in suggestions and (better yet) collaboration on other applications of data-driven computation beyond GUIs, say push-based internet apps.

Software releases: TypeCompose, Phooey, GuiTV

Three related software releases. I am very interested in comments and contributions.

TypeCompose provides some classes & instances for forms of type composition. It also includes a very simple implementation of data-driven computation. I factored it out of a new implementation of Phooey. Phooey is a library for functional user interfaces. Highlights in this 0.3 release:

  • Uses new TypeCompose package, which includes a simple implementation of data-driven computation.
  • New Applicative functor interface.
  • Eliminated the catch-all Phooey.hs module. Now import any one of Graphics.UI.Phooey.{Monad ,Applicative,Arrow}.
  • Phooey.Monad has two different styles of output widgets, made by owidget and owidget’. The latter is used to implement Phooey.Applicative.
  • Self- and mutually-recursive widgets now work again in Phooey.Monad. They wedge in Phooey.Arrow and Phooey.Applicative.

Phooey is also used in GuiTV, a library for composable interfaces and “tangible values”. I’ve also just updated GuiTV to 0.3, to sync with Phooey 1.0.

ICFP ’07 paper draft — comments please

Warning: if you’re on the ICFP program committee and want to preserve double-blind reviewing, please ignore this post.

I’ve been working on an ICFP paper called “Tangible Functional Programming”, revising my last year’s submission on Eros. If you’re interested in taking a look, I’d greatly appreciate any comments, especially before the April 6 submission deadline.

Abstract

We present a user-friendly approach to unifying program creation and execution, based on a notion of “tangible values” (TVs), which are visible and interactive GUI manifestations of pure values. Programming happens by gestural composition of TVs. Our goal is to give end-users the ability to create parameterized, composable content without imposing the usual abstract and linguistic working style of programmers. We hope that such a system will put the essence of programming into the hands of many more people, and in particular people with artistic/visual creative style.

In realizing this vision, we develop algebras for visual presentation and for “deep” function application, where function and argument may both be nested within a structure of tuples, functions, etc. Composition gestures are translated into chains of combinators that act simultaneously on statically typed values and their visualizations.

Here is a figure from the paper, showing one stage of an interactively composed interactive 2D region. The user selects compatibly-typed input and output widgets, typically in different TVs. The result is a new TV that merges the source TVs, except for the connected input and output, which vanish. The sliders control the disk and checker sizes and the checker’s rotation angle.

Edit on March 28:I just added two relevant pointers to the paper’s web page: