Personal tools

Applicative data-driven programming

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m
(Category:Applicative functor -> Functor)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Draft paper -- Comments please''' at the [[Talk:Applicative_Data-Driven_Programming|Talk Page]]
+
I would love to get comments on a short (4.5 page) paper ''draft''. It describes a very simple approach to data-driven computation and its application to GUI programming. Please use the [[Talk:Applicative_Data-Driven_Programming|Talk page]] for comments, or if you prefer you could email me instead.
  +
  +
I'm also very interested in suggestions or (better yet) collaboration on other applications of data-driven computation beyond GUIs, say internet-based.
   
 
== Abstract ==
 
== Abstract ==
   
Graphical user interfaces (GUIs) are usually programmed in an "unnatural" style, in that implementation dependencies are inverted, relative to logical dependencies. We suggest that this reversal results directly from the imperative, data-driven orientation of most GUI libraries. While outputs depend on inputs from a user and semantic point of view, the data-driven approach imposes an implementation dependence of inputs on outputs.
+
: Graphical user interfaces (GUIs) are usually programmed in an "unnatural" style, in that implementation dependencies are inverted, relative to logical dependencies. We suggest that this reversal results directly from the imperative, data-driven orientation of most GUI libraries. While outputs depend on inputs from a user and semantic point of view, the data-driven approach imposes an implementation dependence of inputs on outputs.
   
This paper presents simple, functional interfaces for data-driven programming in general and GUI programming in particular, in which program dependencies directly mirror logical dependencies. The interfaces are structured as ''applicative functors'' (AFs), rather than monads or arrows. Efficiency is retained while abstracting the mechanics of data-driven computation out of client programs and into reusable library code. The implementations of data-driven computation and of GUIs are also quite simple, largely due to structuring them as ''compositions'' of AFs.
+
: This paper presents simple, functional interfaces for data-driven programming in general and GUI programming in particular, in which program dependencies directly mirror logical dependencies. The interfaces are structured as ''applicative functors'' (AFs), rather than monads or arrows. Efficiency is retained while abstracting the mechanics of data-driven computation out of client programs and into reusable library code. The implementations of data-driven computation and of GUIs are also quite simple, largely due to structuring them as ''compositions'' of AFs.
   
 
== Files ==
 
== Files ==
   
* [http://conal.net/papers/data-driven/paper.pdf Paper] (173K PDF)
+
* [http://conal.net/papers/data-driven/paper.pdf Paper] (181K PDF)
 
* [http://conal.net/papers/data-driven/source.tar.gz Literate source] (9K .tar.gz)
 
* [http://conal.net/papers/data-driven/source.tar.gz Literate source] (9K .tar.gz)
   
== Example ==
+
== Preview ==
   
GUI:
+
Using "<hask>g `O` f</hask>" for the ''composition'' of type constructors <hask>g</hask> and <hask>f</hask>, the representation of data-driven computations is simply as follows:
: [[Image:ui1.png]]
+
<haskell>
  +
type Source = (,) (IO () -> IO ()) `O` IO
  +
</haskell>
  +
(The paper generalizes this definition considerably.)
   
Code:
+
And of GUIs:
  +
<haskell>
  +
type UI = (->) Win `O` IO `O` (,) Layout `O` Source
  +
</haskell>
  +
  +
These types are isomorphic to the following:
  +
<haskell>
  +
type Source' a = (IO () -> IO (), IO a)
  +
  +
type UI' a = Win -> IO (Layout, Source' a)
  +
</haskell>
  +
The advantage of the former definitions is that <hask>Source</hask> and <hask>UI</hask> are automatically both [[applicative functor]]s, and so their values may be constructed from primitives via <hask>pure</hask>, <hask><*></hask>, and derived functions.
  +
  +
The paper also provides a more general notion of data-driven sources, as well as a more efficient version of <hask>Source</hask> and a version of <hask>UI</hask> that supports flexible layouts.
  +
  +
Example GUI:
  +
: [[Image:Fruit-shopping.png]]
  +
  +
and corresponding code:
 
<haskell>
 
<haskell>
 
apples, bananas, fruit :: UI Int
 
apples, bananas, fruit :: UI Int
Line 24: Line 24:
 
fruit = title "fruit" $ liftA2 (+) apples bananas
 
fruit = title "fruit" $ liftA2 (+) apples bananas
   
total :: Num a => UI (a -> IO ())
+
total :: UI (Int -> IO ())
 
total = title "total" showDisplay
 
total = title "total" showDisplay
   
Line 31: Line 31:
 
</haskell>
 
</haskell>
 
As illustrated in the paper, slight variations allow for different widget layouts.
 
As illustrated in the paper, slight variations allow for different widget layouts.
  +
  +
== Plans ==
  +
  +
This paper is a simplification of [[Phooey]]'s implementation and includes an altered form of [[TypeCompose]]. I plan to make new releases of those libraries to align them with this paper.
   
 
[[Category:Paper]]
 
[[Category:Paper]]
 
[[Category:User interfaces]]
 
[[Category:User interfaces]]
[[Category:Applicative functor]]
+
[[Category:Applicative Functor]]

Latest revision as of 17:46, 9 January 2011

I would love to get comments on a short (4.5 page) paper draft. It describes a very simple approach to data-driven computation and its application to GUI programming. Please use the Talk page for comments, or if you prefer you could email me instead.

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

Contents

[edit] 1 Abstract

Graphical user interfaces (GUIs) are usually programmed in an "unnatural" style, in that implementation dependencies are inverted, relative to logical dependencies. We suggest that this reversal results directly from the imperative, data-driven orientation of most GUI libraries. While outputs depend on inputs from a user and semantic point of view, the data-driven approach imposes an implementation dependence of inputs on outputs.
This paper presents simple, functional interfaces for data-driven programming in general and GUI programming in particular, in which program dependencies directly mirror logical dependencies. The interfaces are structured as applicative functors (AFs), rather than monads or arrows. Efficiency is retained while abstracting the mechanics of data-driven computation out of client programs and into reusable library code. The implementations of data-driven computation and of GUIs are also quite simple, largely due to structuring them as compositions of AFs.

[edit] 2 Files

[edit] 3 Preview

Using "
g `O` f
" for the composition of type constructors
g
and
f
, the representation of data-driven computations is simply as follows:
type Source = (,) (IO () -> IO ()) `O` IO

(The paper generalizes this definition considerably.)

And of GUIs:

type UI = (->) Win `O` IO `O` (,) Layout `O` Source

These types are isomorphic to the following:

type Source' a = (IO () -> IO (), IO a)
 
type UI' a = Win -> IO (Layout, Source' a)
The advantage of the former definitions is that
Source
and
UI
are automatically both applicative functors, and so their values may be constructed from primitives via
pure
,
<*>
, and derived functions. The paper also provides a more general notion of data-driven sources, as well as a more efficient version of
Source
and a version of
UI
that supports flexible layouts.

Example GUI:

Fruit-shopping.png

and corresponding code:

apples, bananas, fruit :: UI Int
apples  = title "apples"  $ islider (0,10) 3
bananas = title "bananas" $ islider (0,10) 7
fruit   = title "fruit"   $ liftA2 (+) apples bananas
 
total :: UI (Int -> IO ())
total = title "total" showDisplay
 
shopping :: UI (IO ())
shopping = title "Shopping List" $ fruit <**> total

As illustrated in the paper, slight variations allow for different widget layouts.

[edit] 4 Plans

This paper is a simplification of Phooey's implementation and includes an altered form of TypeCompose. I plan to make new releases of those libraries to align them with this paper.