Haskeller Interest in Declarative GUI?

[Liamzy]

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.

[owi]

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.

[atravers]

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

Hanlon's Razor: Not Everyone is Out to Get You

[amazari]

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.

[owi]

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.

[tomjaguarpaw]

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

[owi]

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

[Liamzy]

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).

[Abab9579]

@atravers

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

Hanlon's Razor: Not Everyone is Out to Get You

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.

[Liamzy]

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

Lensmaker

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

===

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

[JBetz]

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 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.

[wiz]

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

[Liamzy]

From Naked Objects to Naked Functions - DZone

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.

[atravers]

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:

(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.

[wiz]

Eh… It is possible to provide a GUI interpretation for some data type via Generics and I’ve seen some, but UX is not that good.

[david-christiansen]

Perhaps iTasks in Clean is a more developed version of this to compare with?

[atravers]

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?

[jaror]

@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

[atravers]

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 (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 (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!

[atravers]

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 if they’re not):

  […] IO is magical (having an implementation but no denotation) […]

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