An alternative to having metadata on the type is to have the generic UI code take the metadata as an extra parameter. For example in generic-random, users can provide a list of "custom generators" to tweak how certain fields are generated. - See tutorial, section "Custom generators for some fields" https://hackage.haskell.org/package/generic-random-1.5.0.1/docs/Generic-Rand...
data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
This is actually legal: type a # b = a and this is preserved in the metadata from Template Haskell queries. Hence, it's possible to have a TH command to derive a `Generic` instance with that metadata. You don't even need to change the `Metadata` field. If you're willing to be hacky, you can also insert an extra `M1` constructor to carry ad-hoc metadata. Li-yao (William: you may get this twice because I forgot to reply to the mailing list the first time.) On 2022-09-09 8:07 PM, William Yager wrote:
Hello all,
I was recently thinking about a generic programming application (auto-generating UI code from data definitions) that would benefit from the ability to "annotate" data definitions. For example, let's say you have a type
data Foo = Foo {barred :: Boolean}
You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps the generic UI code defaults to making a check-box for Boolean values, but you would rather have it be a radio button. It would be advantageous to be able to write something like e.g.
data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
In many languages, you have the ability to annotate data fields in a way which has no bearing whatsoever on the first-order behavior or representation of the type, and is only reflected via the language's generic programming API. For example, in Java, you have
class Foo { @RenderMode(RadioButton) bool barred; }
And in Rust, you have struct Foo { #[render_mode(radio_button)] barred : bool }
In Haskell, I do not believe we have any such system in place for interfacing with Generics.
The closest I am familiar with is from the optparse-generic package, where you write code of the form
data Foo w = Foo {barred :: w ::: Boolean RenderMode RadioButton}
See https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gene...::::
This is basically a clever way to sort of re-create what we have available in Rust or Java, using type families, but with the annoying downside that it makes interacting with your type in normal code much more cumbersome, and is also relatively confusing to read and write.
Compare Rust's Clap package, which is very similar to optparse-generic, but more convenient to work with because the annotations don't impact normal usage of the type.
See https://docs.rs/clap/latest/clap/#example
Would it be technically feasible to add such a thing to GHC's Generics support? I could imagine something like updating the GHC.Generics Meta type's MetaCons constructor to
MetaCons Symbol FixityI Bool *[Annotation]*
Best, Will
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.