...

...

...

...

"Conal" == Conal Elliott writes: Hi Conal,

Conal> Hi Achim, I came to the same conclusion: I want to sweep aside Conal> these OO, imperative toolkits, and replace them with something Conal> "genuinely functional", which for me means having a precise & Conal> simple compositional (denotational) semantics. Something Conal> meaningful, formally tractable, and powefully compositional from Conal> the ground up. As long as we build on complex legacy libraries Conal> (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling Conal> against (or worse yet, drawn into) their ad hoc mental models and Conal> system designs. Conal> As Meister Eckhart said, "Only the hand that erases can write the Conal> true thing." Nicely said... I'm sure you're not the only one desiring to write GUI in "genuinely functional" toolkit, but, being realistic and considering how many people are working on bindings for those "legacy libraries", I doubt we'll see something written from the scratch and usable for "Real World Haskell" soon ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

...

...

...

...

"Conal" == Conal Elliott writes:

Conal> I don't mind if it takes a while, since I'm confident it'll be Conal> worth the wait. Besides, compositionality yields exponential Conal> rewards. Conal> Some more encouragement from my friends: [snip] I'm with you Conal, at least with the philosophy of your friends. The problem is that by body (aka: skills) cannot offer much help now to resist he army ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

On Fri, 30 Jan 2009 15:21:05 +0800 Evan Laforge wrote:

Is there a description somewhere of what the critical flaws have been and are, and what the current problems are to solve before we can finally have a practical declarative and compositional UI library?

In *theory*, that should be in the (recent) research papers themselves, or perhaps in a paper cited by them. I don't know if that's the case, though. (Always annoys me when research papers don't include that.) -- Robin

I haven't really thought about GUIs much in the last decade, but if one were to embark on such an endeavor, I think an appropriate starting point would be SDL with OpenGL. There would be no very little API structure to hinder the pure functional approach, and it would be portable to a wide variety of platforms. SDL includes support Linux/Win/OSX and now the iPhone. Also you'd have unofficial support for another few platforms. The 1st step would be to build a vector graphics lib for Haskell on OpenGL, but after that, perhaps much of Fruit could be fitted in. (Just a WAG, never heard of the API before now)

Wow Luke, this is a nice little package you made :) If you now add support for Bezier curves then you're my hero, then I can get rid of GTK/Cairo for experiments (which turned out to be really slow when rendering large double buffered surfaces...) I also believe that building something on top of OpenGL is the way to go. Too bad that some techniques are patented, like this [1] cool technique for rendering curves directly on the GPU (as far as I know font rendering is still mostly done by the CPU these days) Today hardware is so fast (and tomorrows hardware will double that easily) so that redrawing the whole screen is not an issue anymore, as long as good caching is done to avoid the CPU <-> GPU bottleneck. Regarding rebuilding the whole GUI tree, actually in modern frameworks (like Microsoft's Windows Presentation Foundation or that Piccolo open source framework) every property of every widget *can* be animated on the fly. [1] http://research.microsoft.com/en-us/um/people/cloop/loopblinn05.pdf 2009/1/30 Luke Palmer :

2009/1/30 Rick R

...

I haven't really thought about GUIs much in the last decade, but if one were to embark on such an endeavor, I think an appropriate starting point would be SDL with OpenGL.

There would be no very little API structure to hinder the pure functional approach, and it would be portable to a wide variety of platforms. SDL includes support Linux/Win/OSX and now the iPhone. Also you'd have unofficial support for another few platforms.

The 1st step would be to build a vector graphics lib for Haskell on OpenGL, but after that, perhaps much of Fruit could be fitted in. (Just a WAG, never heard of the API before now)

Well, I've started something like that: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphics-drawingc.... There are some issues with that library: the semantics are not quite right, and its internals are complicated and not easily modified. I want to try again at some point.

However, I think before the 1st step, the SDL bindings ought to be easily installable and usable on Windows -- not first assuming Just The Right Setup.

Luke

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Jan 30, 2009 at 3:50 PM, Achim Schneider wrote:

Antony Courtney wrote:

...

One issue I think you may encounter, though, is that last time I looked, there was still no high-quality, widely available cross-platform 2-D vector graphics library in C or C++! [...]

Xrender. It appears to map exceptionally well onto FP, is available everywhere X is available (that includes Windoze and OS X) and usually is heavily hardware-accelerated. Additionally, we already have a pure Haskell implementation of the client-side protocol included in XHB.

According to Wikipedia: The X Rendering Extension (Render or XRender) is an X Window System extension to implement Porter-Duff image compositing in the X server. Porter-Duff image compositing is cool and useful, but it's at a much lower level than what I meant by 2-D vector graphics library. A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation. Pretty clear how to build a 2-D Scenegraph library like Piccolo on top of Java2D or Quartz or GDI+; much less clear to me how to build something like that directly on top of XRender. -Antony

2009/1/30 Bryan O'Sullivan :

On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney wrote:

...

A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation.

These are the kinds of capabilities provided by Cairo, which is very pleasant to use (PDF-style imaging model) and quite portable. There are already Cairo bindings provided by gtk2hs, too.

There is an even higher-level interface to Cairo, in the form of the diagrams package[1] [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/diagrams-0.1 --Max

Hi, Antony - It's good to see you active on here.

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...]

The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then.

Cairo is now the graphics back end for Firefox, yes? I thought moving to Cairo resulted in a considerable rendering speedup for FF. On Fri, Jan 30, 2009 at 6:31 PM, Peter Verswyvelen wrote:

I found Cairo rather slow, even on the fastest hardware.

Maybe OpenVG will take off one day: http://www.khronos.org/openvg

2009/1/30 Bryan O'Sullivan :

...

Hi, Antony -

It's good to see you active on here.

...

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...]

The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein

When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions. .. IMO the future is fully hardware accelerated rendering on the GPU, like OpenVG. It will take a while before it is common to see glyphs being rendered on the GPU, but I'm sure this is all doable.

There seem to be some older references to an OpenGL backend for Cairo http://www.cairographics.org/OpenGL/ http://www.freedesktop.org/wiki/Software/glitz http://www.usenix.org/events/usenix04/tech/freenix/nilsson.html aiming for hardware acceleration. There doesn't seem to be anything newer than 2006, though, which is puzzling, as the OpenGL backend is still advertized - is it still supported? A common standard would be useful, but OpenVG doesn't look like "ready soon". On the declarative side, there's also SVG.. Claus

Nice! Well well well, we have exciting times ahead! If this implementation is somewhat stable, I guess we need to put a binding on Hackage :) Of course Microsoft provides the new Direct2D API for something similar, but having a multi platform solution is preferable. I also played a bit with an implementation for rendering conics on the GPU: http://staffwww.itn.liu.se/~stegu/GLSL-conics/ That runs about 100 times faster as software rendered Cairo or GDI+ on my PC. On Sun, Feb 1, 2009 at 6:21 PM, Claus Reinke wrote:

A common standard would be useful, but OpenVG doesn't look

...

like "ready soon". On the declarative side, there's also SVG..

Seems I've got to qualify that remark somewhat - apart from some commercial/closed-source implementations, there is also a open source ANSI C one (implemented on top of OpenGL, so it isn't quite the same as direct OpenGL hardware support, but it offers the same API and might be a good target for a Haskell binding..):

http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html

Also, an OpenVG backend for Cairo, which seems to have so many backends that it might be the safest user-level choice?

http://lists.cairographics.org/archives/cairo/2008-January/012833.html http://lists.cairographics.org/archives/cairo/2008-January/012840.html

Claus

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) On Sat, Jan 31, 2009 at 8:54 PM, Duncan Coutts wrote:

On Sat, 2009-01-31 at 13:18 +0100, Peter Verswyvelen wrote:

...

When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions.

With Cairo I am unable to perform full smooth screen redraws of even just a single solid rectangle, and when you are making ZUI (zoomable user interfaces), full screen redraws are not uncommon. "Smooth" here means at least 30 frames per second, but preferably 60 frames per second. It seems not the number of shapes that are rendered is the bottleneck, but the amount of pixels covered. At least that is what I noticed. I guess this is because it is a 100% software renderer, and it might have to perform per pixel conversion when copying to the video card, but I really don't know.

The X11 backend is accelerated if your X server supports it. It uses the XRender extension. If you draw to an image surface then yes that is software rendering. If you're happy to be connected to the X server then you can still do off-screen drawing and again if your X server supports it that can be accelerated too.

Some X servers accelerate some XRender operations and not others. I think some of the gradient fills are problematic.

Duncan

"Claus Reinke" wrote:

though software fallbacks for missing hardware support would seem essential

You mean having widget renderers that don't use any of those frills, don't you? Don't underestimate the breath of the target audience that wants to run things on their sandwich maker... or have processing oomph left to do real work. I don't know how fast eg. mesa renders basic GL in software (at least in comparison to my geForce, it's a slug), but I'd expect it to be a viable choice to render 2d to a dumb framebuffer. GL has also the advantage of being network-transparent[1] and very bandwidth-efficient, at least if you make proper use of display lists and don't use too many different textures. Presenting impressive demos in the spirit of [2] can't have any negative effects (despite users wondering why it doesn't work until they discover that their distribution starts X with --nolisten-tcp) [1]Really. See GLX. [2]http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/demoform.html -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Peter Verswyvelen wrote:

I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare.

Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :)

You might want to try http://www.straightrunning.com/XmingNotes/ xorg-x11 is, after all, freely available, so I don't see any reason why any platform shouldn't support it, as it's The Standard. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Hi Antony,

Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

Jefferson Heard is working on such a thing, called Hieroglyph. Lately I've been helping him simplify the design and shift it toward a clear, composable semantic basis, i.e. "genuinely functional" (as in the Fruit paper), meaning that it can be understood & reasoned about in precise terms via model that is much simpler than IO. In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from the semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement the elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...). Regards, - Conal On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney wrote:

On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan wrote:

...

On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney < antony.courtney@gmail.com> wrote:

...

A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation.

These are the kinds of capabilities provided by Cairo, which is very pleasant to use (PDF-style imaging model) and quite portable. There are already Cairo bindings provided by gtk2hs, too.

Hi Bryan,

Nice to hear from you! Been a while...

Just had a quick look and it does indeed appear that Cairo now supports some of the features I mention above (bounds calculations and hit testing). Cairo has clearly come a long way from when I was last working on Fruit and Haven in 2003/2004; back then it looked like it only provided a way to render or rasterize vector graphics on to bitmap surfaces and not much else.

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, and it looks like the API is still pretty render-centric (e.g. is it possible to obtain the vector representation of rendering text in a particular font?). That might make it challenging to use Cairo for something like the Haven API, but maybe one can live without that level of generality.

In any case: delighted to see progress on this front! Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

-Antony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Conal, Do you have any links to this interesting work of Jefferson Heard? Blogs or something? I failed to Google it, I mainly found his OpenGL TrueType bindings on Hackage and his beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled or stroked curves) as real functions / relations; you don't need fine tessellation anymore since these computational monsters have become so fast that per pixel inside / outside testing are feasible now. It's basically a simple form of real-time ray-tracing :) A quick search revealed another paper using these techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf Cheers, Peter 2009/1/31 Conal Elliott

Hi Antony,

...

Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

Jefferson Heard is working on such a thing, called Hieroglyph. Lately I've been helping him simplify the design and shift it toward a clear, composable semantic basis, i.e. "genuinely functional" (as in the Fruit paper), meaning that it can be understood & reasoned about in precise terms via model that is much simpler than IO.

In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from the semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement the elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...).

Regards,

- Conal

On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney < antony.courtney@gmail.com> wrote:

...

On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan wrote:

...

On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney < antony.courtney@gmail.com> wrote:

...

A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation.

These are the kinds of capabilities provided by Cairo, which is very pleasant to use (PDF-style imaging model) and quite portable. There are already Cairo bindings provided by gtk2hs, too.

Hi Bryan,

Nice to hear from you! Been a while...

Just had a quick look and it does indeed appear that Cairo now supports some of the features I mention above (bounds calculations and hit testing). Cairo has clearly come a long way from when I was last working on Fruit and Haven in 2003/2004; back then it looked like it only provided a way to render or rasterize vector graphics on to bitmap surfaces and not much else.

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, and it looks like the API is still pretty render-centric (e.g. is it possible to obtain the vector representation of rendering text in a particular font?). That might make it challenging to use Cairo for something like the Haven API, but maybe one can live without that level of generality.

In any case: delighted to see progress on this front! Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

-Antony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Oh, and by functional, I mean that it isn't a complete re-wrapping of the library, not that you have IO creeping in all over the place. Pardon my unclearness. On Sun, Feb 1, 2009 at 6:10 PM, Jeff Heard wrote:

Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit testing and I've been out of town this past weekend without much opportunity to work on it. It's not yet a complete functional re-working of Cairo -- for instance, right now patterns aren't supported, and Pango layouts aren't either -- but it should become so. I'll also be forking Hieroglyph to develop a complete, pure-functional 2D graphics toolkit.

-- Jeff

2009/1/31 Peter Verswyvelen :

...

Hi Conal, Do you have any links to this interesting work of Jefferson Heard? Blogs or something? I failed to Google it, I mainly found his OpenGL TrueType bindings on Hackage and his beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled or stroked curves) as real functions / relations; you don't need fine tessellation anymore since these computational monsters have become so fast that per pixel inside / outside testing are feasible now. It's basically a simple form of real-time ray-tracing :) A quick search revealed another paper using these techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf Cheers, Peter 2009/1/31 Conal Elliott

...

Hi Antony,

...

Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

Jefferson Heard is working on such a thing, called Hieroglyph. Lately I've been helping him simplify the design and shift it toward a clear, composable semantic basis, i.e. "genuinely functional" (as in the Fruit paper), meaning that it can be understood & reasoned about in precise terms via model that is much simpler than IO.

In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from the semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement the elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...).

Regards,

- Conal

On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney wrote:

...

On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan wrote:

...

On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney wrote:

...

A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation.

These are the kinds of capabilities provided by Cairo, which is very pleasant to use (PDF-style imaging model) and quite portable. There are already Cairo bindings provided by gtk2hs, too.

Hi Bryan,

Nice to hear from you! Been a while...

Just had a quick look and it does indeed appear that Cairo now supports some of the features I mention above (bounds calculations and hit testing). Cairo has clearly come a long way from when I was last working on Fruit and Haven in 2003/2004; back then it looked like it only provided a way to render or rasterize vector graphics on to bitmap surfaces and not much else.

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, and it looks like the API is still pretty render-centric (e.g. is it possible to obtain the vector representation of rendering text in a particular font?). That might make it challenging to use Cairo for something like the Haven API, but maybe one can live without that level of generality.

In any case: delighted to see progress on this front! Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

-Antony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello I've written a Haskell binding to the Shiva-VG OpenVG implementation. Hopefully it should appear on Hackage in the next couple of days - but for the moment it is available here: http://slackwise.org/spt/files/OpenVG-0.1.tar.gz I've tested it on MacOSX leopard and Windows with MinGW / MSys, if anyone could check it on Linux that would be handy. Thanks. Best regards Stephen

Hi Jeff Thanks. OpenVG is an interesting bit of kit, however... VGU - the higher level layer - would be hard pressed to be less like Haskell, you draw shapes and lines while passing a path handle around. Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. Text functions were added to the OpenVG at version 1.1. In the short term, this limits the usefulness of OpenVG, but if the implementations develop it does look like a good prospect. Stephen 2009/2/2 Jeff Heard :

I will happily check it on Linux. I'm only vaguely familiar with OpenVG... In theory it's a good API, and would support exactly what I'd need for a backend to Hieroglyph that isn't Cairo based, but we'd still need a good image API and probably to bind to Pango to get text and layout support.

That's my thought. On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider wrote:

Stephen Tetley wrote:

...

Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all.

You know, if the Haskell bindings are compositable enough, it shouldn't be a problem to simply load bezier shapes from freetype into other libraries.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks, Peter, for the paper link... I'll look at this, as it's exactly what it sounds like I want for the future of Hieroglyph... 2009/1/31 Peter Verswyvelen :

Hi Conal, Do you have any links to this interesting work of Jefferson Heard? Blogs or something? I failed to Google it, I mainly found his OpenGL TrueType bindings on Hackage and his beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled or stroked curves) as real functions / relations; you don't need fine tessellation anymore since these computational monsters have become so fast that per pixel inside / outside testing are feasible now. It's basically a simple form of real-time ray-tracing :) A quick search revealed another paper using these techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf Cheers, Peter 2009/1/31 Conal Elliott

...

Hi Antony,

...

Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

Jefferson Heard is working on such a thing, called Hieroglyph. Lately I've been helping him simplify the design and shift it toward a clear, composable semantic basis, i.e. "genuinely functional" (as in the Fruit paper), meaning that it can be understood & reasoned about in precise terms via model that is much simpler than IO.

In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from the semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement the elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...).

Regards,

- Conal

On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney wrote:

...

On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan wrote:

...

On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney wrote:

...

A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or GDI+ on Windows ) supports things like computing tight bounding rectangles for arbitrary shapes, hit testing for determining whether a point is inside or outside a shape and constructive area geometry for shape compositing and clipping without dropping down to a raster representation.

These are the kinds of capabilities provided by Cairo, which is very pleasant to use (PDF-style imaging model) and quite portable. There are already Cairo bindings provided by gtk2hs, too.

Hi Bryan,

Nice to hear from you! Been a while...

Just had a quick look and it does indeed appear that Cairo now supports some of the features I mention above (bounds calculations and hit testing). Cairo has clearly come a long way from when I was last working on Fruit and Haven in 2003/2004; back then it looked like it only provided a way to render or rasterize vector graphics on to bitmap surfaces and not much else.

It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, and it looks like the API is still pretty render-centric (e.g. is it possible to obtain the vector representation of rendering text in a particular font?). That might make it challenging to use Cairo for something like the Haven API, but maybe one can live without that level of generality.

In any case: delighted to see progress on this front! Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

-Antony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Antony, My primary claim for success is that the

representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture.

You did something much more meaningful to me that what you say here. It is easy to define a type that satisfies these conditions but is as semantically intractable as IO. As an absurd demonstration, clone some large chunk of the current set of IO primitive interfaces (return, (>>=), getChar, forkIO, various FFI-imported things, ...) into a GADT called NotIO. Then write a 'render :: NotIO a -> IO a' that interprets NotIO as IO. One could call NotIO a "purely functional wrapper". Or we could just use IO itself. In the words of Lewis Carroll:

"That's another thing we've learned from your Nation," said Mein Herr, "map-making. But we've carried it much further than you. What do you consider the largest map that would be really useful?"

*"About six inches to the mile."*

"Only six inches!"exclaimed Mein Herr. "We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all! We actually made a map of the country, on the scale of a mile to the mile!"

*"Have you used it much?" I enquired.*

"It has never been spread out, yet," said Mein Herr: "the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.

While my example and Lewis Carroll's are intentionally absurd, I'm concerned that "purely functional wrappers" can be just as meaningless but less aparently so. I think what you did in Haven (based on memories of our conversations at the time and looking at your slides just now) is substantively different. You gave precise, complete, and tractably simple *denotation* to your types. Complete enough to define the correctness of the rendering process. Does the Haven API live up to your goal of semantic purity for a

vector graphics library? If not, where specifically does it fall short?

Yes, if my understanding about denotational precision and completeness is correct. Is it? Regards, - Conal On Sun, Feb 1, 2009 at 2:37 PM, Antony Courtney wrote:

Hi Conal,

...

...

Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API.

Jefferson Heard is working on such a thing, called Hieroglyph. [...]

In the process, I realized more clearly that the *very goal* of making a purely functional wrapper around an imperative library leads to muddled thinking. It's easy to hide the IO without really eliminating it from

...

semantics, especially if the goal is defined in terms of an IO-based library. Much harder, and I think much more rewarding, is to design semantically, from the ground up, and then figure out how to implement

On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott wrote: the the

...

elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU architectures, ...).

Exciting!

I was very much trying to achieve this with Haven back in 2002:

http://www.haskell.org/haven

As the slides on that page state pretty explicitly, I tried to focus on the semantics and to design a purely functional representation of a vector graphics scene that was not tied to any particular implementation. My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture.

Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short?

I look forward to seeing and reading more about Hieroglyph. The typography and visual presentation of Jefferson's online booklet looks fantastic. A high quality, purely functional vector graphics API for Haskell with portable and robust implementations will be a great thing for the Haskell world.

Regards,

-Antony

Antony Courtney wrote:

Pretty clear how to build a 2-D Scenegraph library like Piccolo on top of Java2D or Quartz or GDI+; much less clear to me how to build something like that directly on top of XRender.

I intended the scene graph to be implemented piece-wise inside, and in terms of, the widgets and merely render with Xrender, something else, or a combination and/or choice of those. Bounding boxes follow directly from the structure of the layout, there's no need to calculate them... a similar argument holds for arbitrary intersections: Widgets just don't overlap. All that stuff fits better into a project like fieldtrip, which of course would be cool to have as a rendering backend. An irc client doesn't even begin to need the same -- compositional -- graphics abilities as say inkscape, it just needs to be able to render stuff next to and over other stuff. To make things even more explicit, the TK should be able to render with ncurses, as long as you don't do any custom paint jobs that you didn't care to implement for ncurses... A 3d modeller implemented with ncurses, software GL and aalib? I guess I'm drifting off. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

2009/1/29 Conal Elliott :

Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled. Any thoughts to throw in, here? Cheers, C

Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote:

The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:

2009/1/29 Conal Elliott :

...

...

Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Well, that is also the idea behind Microsoft's WPF/XAML: they provide a declarative approach to describe the widget tree (specifying what it is, not what is does), and a GUI toolkit (Expression Blend) for artists and designers so they can use a high level tool to build the GUI. You can even define limited behavior and animation in a declarative way. However, I believe those "designer friendly" tools are not designed by designers but by programmers who claim to think what designers want. I work everyday with artists and designers, and these people are frustrated by the limitations and erratic behavior (read "side effects") of most "designer friendly" tools... Furthermore making even a simple GUI requires a lot of collaboration between the developer and the designer, and this screams for a language that both can understand and reason about :-) Also, this approach is nice for "simple" or (should I say mostly form-based GUIs), but as soon as you get into something more complicated, this design won't help you. For example, try to make a mathematical editor like that... or a diagram editor... IMO any GUI framework should work for complicated GUIs as well as easy form based one. I feel the model -> presentation -> view -> reactivity -> model' cycle is still the best approach today for building complex GUIs. Never start with widgets, these are just a possible representation of a model. Although this paradigm comes from Smalltalk, MVC is really functional in my opinion.. If you make that approach compositional *and* fast, you have a winner. Something like FRUIT on steroids (Grapefruit? ;-) but then of course you are stuck with the arrows syntax which feels like drawing graphical circuits with a text editor ;-) 2009/2/2 John A. De Goes

The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote:

Could CSS give us semantic clarity? - Conal

On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote:

...

The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:

2009/1/29 Conal Elliott :

...

...

Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

How do you define "layout" in a way that has a "direct an enormous effect on interaction semantics"??? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 4:31 PM, Conal Elliott wrote:

Hi John,

I'm not sure how to interpret your remarks about "has no effect" and "is best". I guess they're subjective opinions, but maybe I'm missing something objective in your intent. I can see, for instance, at least one way in which layout has a direct and enormous effect on interaction semantics. And while I can see some benefits in choosing CSS, I also see some significant drawbacks, and I wonder if you've factored these drawbacks into your "is best".

- Conal

2009/2/2 John A. De Goes

The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote:

...

Could CSS give us semantic clarity? - Conal

On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote:

The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:

2009/1/29 Conal Elliott : Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Perhaps I should have been more precise: How do you define "layout" and "interaction semantics" in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 9:47 PM, Achim Schneider wrote:

"John A. De Goes" wrote:

...

How do you define "layout" in a way that has a "direct an enormous effect on interaction semantics"???

http://www.youtube.com/watch?v=faJ8N0giqzw

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 3 Feb 2009, at 08:12, Achim Schneider wrote:

"John A. De Goes" wrote:

...

Perhaps I should have been more precise:

How do you define "layout" and "interaction semantics" in such a way that the former has a *necessarily* direct, enormous impact on the latter?

HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks.

HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics.

"Wrecks havoc on the semantics" in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible.

I mostly don't get how a topic discussing how to do GUIs in a beautiful, consistent, composable, orthogonal, functional way got onto the topic of "oh hay, you could do it with html and css". Sure, those two may be declarative languages, but that doesn't make either of them fill the list of features required above! Bob

John A. De Goes wrote:

The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS.

Yes, layout can be separated from interaction. It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] -> Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Regards, apfelmus -- http://apfelmus.nfshost.com

On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes wrote:

I never said, "CSS", I said "like CSS".

Oh, I missed the "like" word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a "style" is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more

...

flexible while being simpler. In any case, a simple primitive

grid :: [[Rect a]] -> Rect a

that arranges widgets in a rectangular grid should be enough for GUIs.

Spoken like a true programmer who knows nothing about usability. :-)

Yes, layout must be very versatile and user definable.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Nor does it need one: http://www.csszengarden.com/ Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 3, 2009, at 10:45 AM, Heinrich Apfelmus wrote:

John A. De Goes wrote:

...

...

Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive

grid :: [[Rect a]] -> Rect a

that arranges widgets in a rectangular grid should be enough for GUIs.

Spoken like a true programmer who knows nothing about usability. :-)

Hehe, well given that CSS doesn't even have such a primitive... :)

Regards, apfelmus

-- http://apfelmus.nfshost.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). For example, you need a changed flag in the state of the text editor. This is updated by a signal from the text widget, and read by the main window (because it affects the title bar text), the File/New and File/Open menu items (need to put up a "Save Changes?" message box) and the main window destroy handler (same thing, but it also needs some way of cancelling the action). Unfortunately, the main window is at one end of the event chain, while the menu is all the way over on the other side. This leads to tricky composition, and widgets which pass the entire state to each other because there's one little bit of information they might need. A related issue is that the application is like a river, in which events flow from one end to the other. Send events back the other way is ugly. Some sort of blackboard design might work better. This conversation made me start thinking about replacing Glade with a Haskell layout language, but I still don't know how to solve the above problems. I should read the FRP papers again. cheers, Fraser. [1] http://thewhitelion.org/darcs/barrie On Mon, Feb 2, 2009 at 8:58 PM, John A. De Goes wrote:

The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:

2009/1/29 Conal Elliott :

...

...

Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- http://thewhitelion.org/mysister

On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wrote:

2009/1/29 Conal Elliott :

...

Hi Achim,

I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something "genuinely functional", which for me means having a precise & simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs.

As Meister Eckhart said, "Only the hand that erases can write the true thing."

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

Again, my goal would not be a "purely functional" library, because even IO is "purely functional". My goal is a "denotational" library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning. The initial gut feeling I have is that one should just ignore any

notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C

The Fruit paper, "Genuinely Functional User Interfaceshttp://www.apocalypse.org/pub/u/antony/work/pubs/genuinely-functional-guis.p...", gives a semantic model, which could be a starting place for thinking about possibilities. At the very least, I'd like to take it to 3D. The idea there is that a UI is a function from flows (behaviors/signals) to flows, where the input includes mouse & keyboard stuff and the output includes an image. An image is, as in Pan, a function from R^2 -> Color, where color includes partial opacity. When UIs are transformed in time and/or space, they correspondingly see inversely-transformed input, thanks to a general principle of transforming functions. - Conal

On Mon, Feb 2, 2009 at 3:28 PM, Conal Elliott wrote:

On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wrote:

...

<snip>

...

I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives?

Again, my goal would not be a "purely functional" library, because even IO is "purely functional". My goal is a "denotational" library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning.

Well, that is essentially what I meant but your point about clarity is taken. A truly mathematical semantic model is above & beyond what is meant by "purely functional".

...

The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled.

Any thoughts to throw in, here?

Cheers, C

The Fruit paper, "Genuinely Functional User Interfaces", gives a semantic model, which could be a starting place for thinking about possibilities. At the very least, I'd like to take it to 3D. The idea there is that a UI is a function from flows (behaviors/signals) to flows, where the input includes mouse & keyboard stuff and the output includes an image. An image is, as in Pan, a function from R^2 -> Color, where color includes partial opacity. When UIs are transformed in time and/or space, they correspondingly see inversely-transformed input, thanks to a general principle of transforming functions.

Thanks. I'm reading it now. Cheers, C