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 <antony.courtney@gmail.com> wrote:
Hi Conal,

On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott <conal@conal.net> wrote:
>> 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 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, ...).

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