...

From briefly reading the wiki page https://wiki.haskell.org/Tangible_Value, it looks like it relies on Applicative functors for combining values. So maybe the missing piece for sum-types was Selective functors https://hackage.haskell.org/package/selective?

Gustavo Bicalho

Well spotted! I did not know selective applicative functors (SAFs), thanks for mentioning! Indeed `branch` seems to be all that is necessary to get forms for sum types going. In the talk [1] Andrey mentions that SAFs have a bind, but only for enumerable inputs. The papers state that "all effects are declared statically". If we equate "effect" with "form input" then for recursive types like lists this would mean to pre-define an infinite number of fields and have the user select a finite number of them. I wonder whether that is feasible with html forms. Maybe forms (in the html sense) are a red herring for what I am after. Both the Grace and tangible values demos immediately process changes to inputs, there is no distinction between inputting the data and having the data processed: they are event-driven systems. As is JavaScript with its `oninput` and `onchange` functions. So there are two sub-problems here: The first problem is to programmatically generate html elements by JavaScript functions that can build all finite values of a given Generic Haskell type, and nothing else. The second problem is to scrape the thusly generated elements and re-assemble them into a Haskell value on the server side. The second problem is usually solved by html forms, but there may be other means.  Olaf [1] https://dl.acm.org/doi/abs/10.1145/3341694#