[Haskell-cafe] Generic "annotations" on type definitions

[Will Yager]

The generic-random approach is interesting. I will ruminate on that. I could also see allowing the user to pass in a special "annotator" type which is structurally similar to the type being processed (e.g. it has constructor and field names like the original object but with "_" at the end) but instead of containing any data, it just contains annotations and is "generically zipped" with the generic representation of the first object. 

I would prefer not to use TH if possible. The fact that Haskell's generic programming is generally sufficiently powerful to avoid using TH is really nice, in my opinion. It's much better than Rust in this regard. 

> On Sep 9, 2022, at 17:49, Li-yao Xia <lysxia at gmail.com> wrote:
> 
> 
> 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-Random-Tutorial.html
> 
> > 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-Generic.html#t::::
>> 
>> 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.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220909/72376440/attachment.html>