# Haskeller Interest in Declarative GUI?

**URL:** <https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384>\
**Category:** Uncategorized\
**Created:** [August 22, 2023, 8:25am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384 "2023-08-22T08:25:29Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [August 25, 2023, 12:35pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/21 "2023-08-25T12:35:58Z")

</div>

Edit: blew off a bit about Nix, and am embarrassed about it, especially since you were trying to be helpful. Thank you for mentioning the old Nix flake as a possible solution.

Rest of old content:

And, tbh, if @owi doesn’t get back to you, you might have license to seize the Hackage name, or just fork it.

---

<div class="post-metadata">

**Author:** ![owi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/owi/32/251_2.png) [@owi](https://discourse.haskell.org/u/owi)\
**Post date:** [August 25, 2023, 12:55pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/22 "2023-08-25T12:55:49Z")

</div>

Hi. I don’t have time or interest in maintaining Haskell packages these days, since a few years when family life started. I’d be happy to grant admin rights and perhaps move the project to a separate org on GitHub, if anyone wants to take it over. Let me know.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [August 25, 2023, 1:04pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/23 "2023-08-25T13:04:49Z")

</div>

Well, would you look at that - no _“seizing”_ required:

> **[Hanlon's Razor: Not Everyone is Out to Get You](https://fs.blog/mental-model-hanlons-razor/)**
>
> Hanlon’s Razor teaches us not to assume the worst intention in the actions of others. Understanding Hanlon’s Razor helps us see the world in a more positive light, stop negative assumptions, and improve relationships.

---

<div class="post-metadata">

**Author:** ![amazari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/amazari/32/3325_2.png) [@amazari](https://discourse.haskell.org/u/amazari)\
**Post date:** [August 25, 2023, 3:55pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/24 "2023-08-25T15:55:16Z")

</div>

Thanks for chiming in!

To be clear, I have no intention to take-over/seize neither the GitHub project nor the Hackage name, let’s not go ahead of ourselves @Liamzy🙂 Thanks for proposing anyway!

I am currently experimenting with updating the build tooling and dependencies, then will look into porting the logic to gtk4.  
If ever a working solution emerges (big IF), I guess it would be named gi-gtk4-declarative, anyway. The APIs are different enough, and could/should co-exist in different packages.  
I already feel the pain of gi-gtk sharing a name for both its GTK 3 and GTK 4 bindings. Wouldn’t want that for users of a hypothetical GTK 4 port of gi-gtk-declarative.

---

<div class="post-metadata">

**Author:** ![owi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/owi/32/251_2.png) [@owi](https://discourse.haskell.org/u/owi)\
**Post date:** [August 25, 2023, 5:37pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/25 "2023-08-25T17:37:28Z")

</div>

FWIW, I think that makes a lot of sense if the goal is to use GTK 4.x. I’m not that familiar with the new API, other than noticing it’s probably not a straightforward port.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [August 25, 2023, 7:56pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/26 "2023-08-25T19:56:57Z")

</div>

Would you mind granting me rights on Hackage so I can bump bounds when new dependency versions get released? I’m taking care of a few packages in that way already. (I don’t intend to actually release any code, just make Hackage revisions if necessary.)

This is me: [Tom Ellis | Hackage](https://hackage.haskell.org/user/tomjaguarpaw)

---

<div class="post-metadata">

**Author:** ![owi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/owi/32/251_2.png) [@owi](https://discourse.haskell.org/u/owi)\
**Post date:** [August 26, 2023, 6:29am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/27 "2023-08-26T06:29:56Z")

</div>

@tomjaguarpaw done, also added you to the GH repo.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [August 26, 2023, 11:00am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/28 "2023-08-26T11:00:25Z")

</div>

Thank you so much for all your work! I’m looking forward to trying your library once I can finally get it running… (busy trying to build a GUI in monomer right now).

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [August 27, 2023, 1:18am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/29 "2023-08-27T01:18:01Z")

</div>

> [@atravers](#):
>
> Well, would you look at that - no _“seizing”_ required:
> 
> [https://fs.blog/mental-model-hanlons-razor/](https://fs.blog/mental-model-hanlons-razor/)

Sorry for off-topic, but I personally cannot accept hanlons’ razor. People were actually trying to get me in trouble for lots of situations. I guess it depends on the society.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [August 27, 2023, 3:16am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/30 "2023-08-27T03:16:36Z")

</div>

Monomer strictly doesn’t need lens; for a lot of common widgets there’s a lens-free version.

But from what I’ve read, optics are crucial to concise Haskell, so it’s a good skill to have (next stop on Haskell learning after monads and monad transformers, imo).

The best way to pick up lenses is not through the papers, but actually to use them. Once you’ve gotten some practice:

> **[Lens Apprentice](https://www.codewars.com/kata/5cd99b8af446b0000ed8e615)**
>
> Credit / Follow Up: 
> This spec acts as an easier / simpler van Laarhoven prelude to the more general problem of implementing various Profunctor Optics (such as lenses, traversals, prisms etc.). Fo...

> **[Lensmaker](https://www.codewars.com/kata/54258ffb430ca2e4b5000239)**
>
> Implement a small ("van Laarhoven" style) lens library including lenses, prisms, traversals, folds, and isos. 
> Lenses, or "functional references" are a toolkit for "focusing" on inner parts of val...

Then, try the papers.

Also, this seems to be the new standard in lenses these days, but monomer seems to be married to Kmett’s Lens library.

[https://hackage.haskell.org/package/optics-0.4.2.1/docs/Optics.html](https://hackage.haskell.org/package/optics-0.4.2.1/docs/Optics.html)

===

As for monomer, the best on-ramp is to dissect fjvallarino’s examples, get them working, and modify them.

---

<div class="post-metadata">

**Author:** ![JBetz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jbetz/32/3669_2.png) [@JBetz](https://discourse.haskell.org/u/JBetz)\
**Post date:** [September 20, 2023, 4:33pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/31 "2023-09-20T16:33:01Z")

</div>

Haskell and functional programming in general need their equivalent of Naked Objects in order to bring any real value to the GUI space. Even [https://github.com/NakedObjectsGroup/NakedObjectsFramework](https://NakedFunctions) is further along in this direction than anything currently available in Haskell.

FRP is neat but only a small part of the problem. If you’re still manually generating HTML or widget bindings for all of your data types, it’s not declarative. Defining and automatically deriving a GUI typeclass would be a good start. Things like layout and styling for individual data types would still need to be defined by the user, but weaving everything together should be done by the framework.

I’m deeply interested in this problem, but am currently working on it in Smalltalk, not Haskell. The basic principles are the same, though, and it shouldn’t be difficult to translate from one to the other.

---

<div class="post-metadata">

**Author:** ![wiz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wiz/32/2408_2.png) [@wiz](https://discourse.haskell.org/u/wiz)\
**Post date:** [September 20, 2023, 5:12pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/32 "2023-09-20T17:12:48Z")

</div>

What’s this Naked Objects thing? The github link shows some C# code and docx’s, but no screenshots or quick demos.

---

<div class="post-metadata">

**Author:** ![Liamzy](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@Liamzy](https://discourse.haskell.org/u/Liamzy)\
**Post date:** [September 20, 2023, 5:49pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/33 "2023-09-20T17:49:15Z")

</div>

> **[From Naked Objects to Naked Functions - DZone](https://dzone.com/articles/from-naked-objects-to-naked-functions)**
>
> Learn how to get started with Naked Functions, a functional programming approach that expands on Naked Objects.

Interesting side project of the Naked Objects folks.

This actually very interesting; it sounds a bit like implementing Servant for GUI.

To an extent, I’m surprised that no one has tried it in the Haskell-side; startApp @MyGUIInterface, type-safe GUI programming, possibly with effect systems.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 20, 2023, 7:04pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/34 "2023-09-20T19:04:18Z")

</div>

From that DZone article:

> [@](#):
>
> […] with Naked Functions you define only immutable domain types and pure side-effect free domain functions. You do not typically need to write _any_ I/O at all, because the Naked Functions framework handles I/O with the client and the database transparently.

…and from [A Functional I/O System](https://www2.ccs.neu.edu/racket/pubs/icfp09-fffk.pdf):

> [@](#):
>
> (first page)
> 
> We have implemented this vision with a simple framework for purely functional I/O. Using this framework, students design, implement, and test plain mathematical functions over numbers, booleans, string, and images. Then the framework wires them up to devices and performs all the translation from external information to internal data (and vice versa)—just like every other operating system.

…so there appears to be a superficial resemblance between the two described approaches. But closer scrutiny of both systems may prove otherwise.

---

<div class="post-metadata">

**Author:** ![wiz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/wiz/32/2408_2.png) [@wiz](https://discourse.haskell.org/u/wiz)\
**Post date:** [September 21, 2023, 11:11am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/35 "2023-09-21T11:11:56Z")

</div>

Eh… It is [possible](http://wiki.haskell.org/AutoForms) to provide a GUI interpretation for some data type via `Generics` and I’ve seen some, but UX is not that good.

---

<div class="post-metadata">

**Author:** ![david-christiansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/david-christiansen/32/2404_2.png) [@david-christiansen](https://discourse.haskell.org/u/david-christiansen)\
**Post date:** [September 21, 2023, 12:05pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/36 "2023-09-21T12:05:48Z")

</div>

Perhaps [iTasks](https://wiki.clean.cs.ru.nl/ITasks) in Clean is a more developed version of this to compare with?

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 21, 2023, 12:17pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/37 "2023-09-21T12:17:33Z")

</div>

This is curious:

> [@](#):
>
> The iTask system ( **iTasks** ) is a task-oriented programming toolkit for programming workflow support applications in Clean.
> 
> With this toolkit, interactive systems can be specified using combinators in a very high level declarative monadic style.

…could it (and that _“style”_ ) be ported to Haskell?

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [September 21, 2023, 12:26pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/38 "2023-09-21T12:26:28Z")

</div>

> [@atravers](#):
>
> could it (and that _“style”_ ) be ported to Haskell?

A simplified version of it has already been ported:

> **[GitHub - timjs/tophat-haskell: TopHat implementation in Haskell](https://github.com/timjs/tophat-haskell)**
>
> TopHat implementation in Haskell

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 21, 2023, 11:35pm UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/39 "2023-09-21T23:35:19Z")

</div>

So _that’s_ what TopHat is! It’s appeared several times now in various Web-searches, but I’ve been ignoring it due to the name - I thought it was connect to the old Hat debugger for NHC (an early Haskell compiler). Now searching for relevant papers:

[TopHat: A formal foundation for task-oriented programming](https://www.cs.ru.nl/~steenvoo/papers/ppdp-tophat.pdf) (2019)

> [@](#):
>
> (page 4 of 22)
> 
> **3.5 Tasks are never done**
> 
> Tasks never terminate, they always keep reacting to events. Editors can always be changed or cleared, and step combinators move on to new tasks.

…that’s interesting:

> [@](#):
>
> (page 21 of 36)
> 
> We need the concept of a ‘process’ as opposed to a function. Intuitively a process is something that (in general) is geared towards continuation while a function is geared towards termination.
> 
> [The impact of the lambda calculus in logic and computer science](https://repository.ubn.ru.nl/bitstream/handle/2066/17274/13362.pdf) (1997)

Another analogous type could be the _stream processor_ (`SP a b`, of _Fudgets_ fame), albeit one with only the `Get` and `Put` constructors (so no `End`). But in earlier versions, `SP a b` was an isomorphism for `([a] -> [b])`, which in turn is reminiscent of the early work by Henderson and Stoye on functional OSs - some ideas just seem to be timeless!

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 22, 2023, 1:19am UTC](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384/40 "2023-09-22T01:19:47Z")

</div>

But (yes, there is one) having said all that…some may consider _“a very high level declarative monadic style”_ to be something of an oxymoron:

- there are those who would regard the monadic interface itself as being too imperative,

- while others will want the relevant monadic type/s to be **completely** specified/declared/denoted in Haskell (and [be dissatisfied](https://stackoverflow.com/a/16444789) if they’re not):

This is one of those times when I’m glad to still be an ol’ _“CLI driver”_ `(`at least for now `;-)`

[Previous page](https://discourse.haskell.org/t/haskeller-interest-in-declarative-gui/7384.md?page=1)