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

[Conal Elliott]

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 at gmail.com>wrote:

> Hi Conal,
>
> On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott <conal at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/71e00d29/attachment.htm