For what's worth, from my perspective as someone fairly evenly split between theory and practice, FRP should still be seen as experimental and not ready for prime time. There are still some fundamental unresolved problems in theory, and I'm not seeing huge evidence that the practice is worked out either. I'm interested and it's worth keeping an eye on, but I do fear it's one of the better examples of some people on the academic side declaring they've got the One True Way to program when their One True Way can barely hold together in toy programs. I hope to see more good work come out of this field, though. I'm cautiously optimistic there's something there.

(On the other hand, I do also think that one of the problems FRP faces is in trying to bind to a very not-functional world. UI toolkits in particular are deeply, fundamentally imperative, and such massive endeavors that the idea of replacing one with a functional equivalent is laughable, because the resources aren't there, even though there aren't any fundamental blockers. Needing to hook up your FRP to such toolkits to get them to do anything is a huge up-front penalty to pay to even get one started.)

What about going onto, say, Linux and making your own graphical toolkit from the ground up?

As I said, it's a massive undertaking. The minimal acceptable toolkit (to say nothing of competing with GTK or QT, just getting the minimal toolkit that users will tolerate) is an immense amount of work. Quite a lot of it is essential complexity, the things that textboxes do that are simply expected and are true representations of complexity, not accidental artifacts of the paradigm used. Functional programming may or may not help with accidental complexity but nothing can duck the essential complexity. I'd estimate that even a minimal toolkit would be on par with the time invested into GHC itself, and to seriously compete, tack a couple of orders of magnitude on there.

In a world where everybody implements MVC web framework in their favorite language, reimplements window managers in their favorite language, and reimplements all manner of other software simply because it wasn't in their favorite language... there's a reason all the communities just bind to GTK, QT, and wxWidgets and don't reimplement widget frameworks from scratch in their favorite language, even for languages much better funded and bigger than all the functional programming communities put together. Just the bindings can be major and in some cases unsustainable efforts for smaller communities.

Perhaps if you need a comprehensive toolkit that supports the various widgets and gestures in contemporary toolkits, it is a big undertaking (probably not that massive, IMO).

A minimal toolkit that can do interesting things is a few weeks of work in Haskell. Here's an implementation of one: https://github.com/Peaker/bottle/tree/master/bottlelib/Graph...

It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work (it's simply not our focus in the project).

I was citing the amount of work to create a minimal acceptable toolkit to a programmer on the street, the sort of toolkit you'd point a hostile Python programmer to to say "Yes, we have a native toolkit", not the toolkit that you'd use to convince an already-converted Haskell user. Bear in mind that Tk prior to their relatively recent theme work was not that toolkit either! And that was actually a pretty decent kit, with layout managers, a nice text widget, tabs, all the basic stuff you'd need, if not the fanciest ever.

* It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work*

So it's minimal AND incomplete. Not even minimal and complete. That's what the parent was saying. And it will likely stay that way (as it's not even your focus in the project), and be forgotten.

There are tons of toolkits like that.