Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense

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