separating IO from logic — example

This post is a teaser for an article in my TiddlyWiki-based journal. The article illustrates an approach to separating logic and IO using the TV library. The TV approach clarifies the pure logic part and the IO part and is more conveniently composable than the mixed logic/IO formulation.

I’ve just released TV-0.2, which omits GUI functionality. That functionality is now present in the small new package GuiTV. The reason for this split is that the GUI support depends on wxHaskell, which currently can be difficult to install. Only TV (not GuiTV) is needed for this example.

See the article here.

Edit of Feb 13: If you tried the TiddlyWiki article in Opera and got an error, please try again. Problem fixed. (Slight difference in regexp handling in Opera vs FF & IE.)

Edit of March 5: This article was inspired by an example in Don Stewart’s “Programming Haskell” post.

Software releases

Last week I released three Haskell libraries: DeepArrow 0.0, Phooey 0.1, and TV 0.0.

These libraries came from Eros, which aims at creating a right-brain-friendly (concrete, non-linguistic) “programming” process. I’ve had a growing intuition over the last fifteen years that media authoring tools can be usefully looked at as environments for functional programming. I’d been wondering how to map a user’s gestures into operations on a functional program. Lots of noodling led to ideas of composable interfaces and “tangible values” (term thanks to Sean Seefried) and gestural composition in Eros.

Eros is more complicated than I like, so I started splitting it into pieces:

  • Phooey is a functional GUI library that has much of Eros’s GUI implementation techniques, but much more carefully structured than in the Eros paper.
  • DeepArrow has the general notion of “deep application”
  • TV has the algebra of composable interfaces, or visualizations of pure values, and it has tangible values, which are separable combinations of interface and value. It uses Phooey to generate GUIs very simply from interfaces

Although these libraries came from Eros, I’d like to see other applications as well.

Where am I going with library development?

  • Figure out how to support simple GUIs and Eros’s gesturally composable GUIs, without code/library replication.
  • Re-implement Eros on top of simpler pieces.
  • Refactor Pajama into reusable libraries and release.
    • Building and optimizing “expressions”
    • Common sub-expression elimination
    • Generation of Java code
    • Perhaps other back-ends besides Java
    • Pajama, on top of these pieces

Edit of March 5, 2007: TV is now split into a core TV package, with no GUI functionality, and GuiTV, with Phooey-based GUI creation. The reason for the split is that Phooey depends on wxHaskell, which can be difficult to install.

New Pajama wiki

Edits:

  • 2008-11-24: The wiki broke a few months ago, after a server change. I’ll restore it someday, when I get Pajama into releasable shape.

I set up a new wiki for Pajama (interactive, continuous, web-embeddable images). Please try it out and leave comments on the wiki or email them to me.

I’m very interested in help with Pajama, particularly:

  • Replacing the remaining old code from Pan (done while I was at Microsoft Research). Most of the code has been rewritten and simplified, including the complicated code motion stuff (common subexpression elimination and loop hoisting), code generation (nicely exploiting Java), and GUI construction.
  • Getting it whipped into shape to be a open source project.
  • Applying the (domain-independent) compiler to other domains (sound, 3D, …).
  • Improvements to the wiki, including easier uploading of examples and automatic generation of galleries.
  • Integration of Pajama and Eros (end-user syntax-free authoring of functional programs).

On wiki software selection: After looking around at different engines, including a visit to #wiki and WikiMatrix, I picked MoinMoin. It satisfies my requirements nicely: Java applet embedding (as generated by the Pajama compiler), free, wysiwyg page editing and a friendly implementation/extension language, namely Python. Then I started learning Python, which is a reasonably nice programming language for customizing the wiki server. My first Python program is a wiki macro that makes it fairly easy to embed Pajama effects in a wiki page.

Non-syntactic, end-user, functional programming

(This is an edited version of a post made on April 11 that somehow became inaccessible from my main blog page.)

I have a draft paper called “Functional Programming by Interacting with Concrete Values”. I’m very excited about this research direction as a way to let people program without turning them into programmers. A concrete form of this goal is enable artists to make and share their own software tools (parameterized image effects), while staying in an artistic creative mode.

An excerpt from the introduction:

Suppose users of interactive programs could also create such programs with a simple extension of their current style of interaction. First, such a development would enable many more people to create and share computational content. Second, it would allow this content to be created without imposing the abstract, linguistic mode of creativity. This freedom may give birth to new kinds of programs whose creation is nurtured by a concrete and visual environment.

Comments please (related work, ideas, typos, unclear bits, etc)!

Edit 2008-04-17: The paper didn’t get accepted in 2006. Thanks to very helpful review comments, and a lot of rewriting, the paper did get accepted in 2007, under the title “Tangible functional programming”.

P.S. to “Pajama site improved”

Please see this this January post for an overview of Pajama.

Pajama now runs on Java 1.4 and up, not just 1.5, thanks to Retroweaver, a class file rewriter.

Pajama site improved

The Pajama site is much prettier & friendlier now, thanks to Holly. She organized the image effects into several groups (with overlap), chose settings to show them off, and added “toy tips” suggesting what to try.

I would love to get comments and suggestions.

Unifying and generalizing spatial transformation

(Edit 2008-01-14: updated formatting.)

I’m trying out an idea I had a while back for unifying and generalizing different notions of spatial transformation in Pan (and spatial & temporal transformation in Fran. The three notions are transforming a point, an image (which is a function from point to alpha), and an image filter (which is a function from image to image). A basic “transform” is a function from points to points. To transform a point, just apply the function. To transform an image, inversely transform the points fed into the image. To transform a filter, inversely transform the source image and forward transform the result image.

type VectorE       = (DoubleE,DoubleE)
type PointE        = (DoubleE, DoubleE)
type Image c       = PointE -> c
type HyperFilter c = Filter c -> Filter c

Then for instance, scaling has these three variants:

scaleP :: VectorE -> TransformE
scaleP (sx,sy) =  (x,y) -> (sx * x, sy * y)

scale :: VectorE -> Filter c
scale (sx,sy) = (. scaleP (1/sx, 1/sy))

atScale :: VectorE -> HyperFilter c
atScale (sx,sy) xf =
  scale (sx,sy) . xf . scale(1/sx,1/sy)

Hyperfilters allow some beautifully modular formulations of filters.

Note how in scale and atScale, I’m inverting the scaling. Exactly this pattern of inversion happens for other types of transformations as well (translation, rotation, swirl, etc). The new idea is to capture this inversion pattern once in a general rule for transforming functions. A type class specifies types that can be spatially transformed, which is direct for points, a do-nothing for numbers and booleans, distributes over tupling, and works similarly to atScale above for functions. To make this fly, I’m changing my representation of points and vectors from pairs to data types, which makes the code less succinct but is more strongly typed.

There’s a big catch in this plan: I only know how to handle invertible transformations, which rules out, e.g., tiling.

Here’s the class of transformable values:

class ITrans a where
  iTrans :: ITransformE -> a -> a

and the handling of functions:

instance (ITrans a, ITrans b) => ITrans (a->b) where
iTrans xf f = iTrans xf . f . iTrans (invIT xf)

The type of invertible transforms simply has a pair of transforms:

data ITransformE =
  ITransformE { itForward  :: TransformE
              , itBackward :: TransformE }

invIT :: ITransformE -> ITransformE
invIT (ITransformE forw back) = ITransformE back forw

Besides doing what I already do more uniformly, this generalized approach to transformation should be just the thing for interactive images, which may be neatly formulated again, as functions.

Pajama!

I am working on a new implementation, called Pajama, of the image synthesis embedded language Pan, this time generating Java applets. The advantages over Pan will be

  • Easy to run examples. Anyone with Java 1.5 or better can simply visit a web page to see and interact with the examples.
  • Examples run on all major platforms (wherever Java 1.5 runs), while Pan ran on Windows only.
  • The Pajama compiler runs on all platforms supporting GHC and the java compiler. In contrast, the Pan compiler ran only under Windows and only with Microsoft’s Visual C++ compiler. Worse yet, Pan used a GUI library (WTL) that Microsoft no longer supports. I haven’t been able to run the Pan compiler for quite a while now.

The disadvantage of Pajama over Pan is speed. Trig speed is quite a bit slower, and I suspect array accesses are also. Mustang (Java 1.6) improves trig performance considerably, though only with the server JVM, but almost everyone would be using the client JVM. I hope speed improves over time.

Quite a lot of Pajama is already working. I have first examples running here. More on the way.

April 13 edit: Pajama now runs on Java 1.4 and up, not just 1.5, thanks to Retroweaver, a class file rewriter.