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

Creighton Hogg wchogg at gmail.com
Mon Feb 2 16:57:00 EST 2009


On Mon, Feb 2, 2009 at 3:28 PM, Conal Elliott <conal at conal.net> wrote:
> On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg <wchogg at gmail.com> 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


More information about the Haskell-Cafe mailing list