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

Li-yao Xia lysxia at gmail.com
Fri Sep 9 21:48:25 UTC 2022


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220909/13a8739f/attachment.html>


More information about the Haskell-Cafe mailing list