<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">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. </div><div dir="ltr"><br></div><div dir="ltr">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. </div><div dir="ltr"><br><blockquote type="cite">On Sep 9, 2022, at 17:49, Li-yao Xia <lysxia@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>An alternative to having metadata on the type is to have the
generic UI code take the metadata as an extra parameter.<br>
</p>
<p>For example in generic-random, users can provide a list of
"custom generators" to tweak how certain fields are generated.</p>
<p>- See tutorial, section "Custom generators for some fields"
<a class="moz-txt-link-freetext" href="https://hackage.haskell.org/package/generic-random-1.5.0.1/docs/Generic-Random-Tutorial.html">https://hackage.haskell.org/package/generic-random-1.5.0.1/docs/Generic-Random-Tutorial.html</a></p>
<p>> data Foo = Foo {barred :: Boolean # RenderMode RadioButton}<br>
</p>
<p>This is actually legal: type a # b = a</p>
<p>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.<br>
</p>
<p> Li-yao</p>
<p>(William: you may get this twice because I forgot to reply to the
mailing list the first time.)<br>
</p>
<div class="moz-cite-prefix">On 2022-09-09 8:07 PM, William Yager
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAG8oi1Myx+AoBwpJGi--RQpQj7gd4qREoQN2uQqYtcY9f-WegQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>data Foo = Foo {barred :: Boolean} </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>data Foo = Foo {barred :: Boolean # RenderMode
RadioButton} <br>
</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>class Foo {</div>
<div><a class="gmail_plusreply" id="plusReplyChip-0" moz-do-not-send="true">@RenderMode(RadioButton)</a><br>
</div>
<div>bool barred;</div>
<div>}</div>
<div><br>
</div>
<div>And in Rust, you have</div>
<div>struct Foo {</div>
<div>#[render_mode(radio_button)]</div>
<div>barred : bool</div>
<div>}</div>
<div><br>
</div>
<div>In Haskell, I do not believe we have any such system in
place for interfacing with Generics.</div>
<div><br>
</div>
<div>The closest I am familiar with is from the optparse-generic
package, where you write code of the form</div>
<div><br>
</div>
<div>data Foo w = Foo {barred :: w ::: Boolean <?>
RenderMode RadioButton}</div>
<div><br>
</div>
<div>See <a href="https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::" moz-do-not-send="true" class="moz-txt-link-freetext">https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::</a>::</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>See <a href="https://docs.rs/clap/latest/clap/#example" moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.rs/clap/latest/clap/#example</a></div>
<div><br>
</div>
<div>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 </div>
<div><br>
</div>
<div>MetaCons Symbol FixityI Bool <b>[Annotation]</b><br>
</div>
<div><br>
</div>
<div>Best,</div>
<div>Will</div>
<div><br>
</div>
<div><br>
<a class="gmail_plusreply" moz-do-not-send="true"><br>
</a></div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
<span>_______________________________________________</span><br><span>Haskell-Cafe mailing list</span><br><span>To (un)subscribe, modify options or view archives go to:</span><br><span>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</span><br><span>Only members subscribed via the mailman list are allowed to post.</span></div></blockquote></body></html>