Conal Elliott

Last year I stumbled across a simple representation for partial information about values, and wrote about it in two posts, A type for partial values and Implementing a type for partial values. Of particular interest is the ability to combine two partial values into one, combining the information present in each one.

More recently, I played with unambiguous choice, described in the previous post.

This post combines these two ideas. It describes how to work with partial values in Haskell natively, i.e., without using any special representation and without the use restrictions of unambiguous choice. I got inspired to try removing those restrictions during stimulating discussions with Thomas Davie, Russell O’Connor others in the #haskell gang.

You can download and play with the library shown described here. There are links and a bit more info on the lub wiki page.

Edits:

• 2008-11-22: Fixed link: Implementing a type for partial values
• 2008-11-22: Tidied introduction

Continue reading ‘Merging partial values’ »

Last year I stumbled across a simple representation for partial information about values, and wrote about it in two posts, A type for partial values and Implementing a type for...

The Reactive library implements functional reactive programming (FRP) in a data-driven and yet purely functional way, on top of a new primitive I call “unambiguous choice”, or unamb. This primitive has simple functional semantics and a concurrent implementation. The point is to allow one to try out two different ways to answer the same question, when it’s not known in advance which one will succeed first, if at all.

This post describes and demonstrates unamb and its implementation.

Continue reading ‘Functional concurrency with unambiguous choice’ »

The Reactive library implements functional reactive programming (FRP) in a data-driven and yet purely functional way, on top of a new primitive I call “unambiguous choice”, or unamb. This primitive...

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.

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

In my previous post, I gave an interface for a type of partial values and invited implementations. Here’s mine, which surprised me in its simplicity.

Continue reading ‘Implementing a type for partial values’ »

In my previous post, I gave an interface for a type of partial values and invited implementations. Here’s mine, which surprised me in its simplicity.

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’ »

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

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.

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

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.

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