Hi,<br><br>&gt; But TH gives me the same feeling as other language features that have<br>&gt; been described as &quot;bolted on.&quot; Also, TH is both library and built-in<br>&gt; syntax (via an extension) which feels strange to me.<br>
<br>I don&#39;t understand why the library/extension duality is a problem. I would say that the best approach is to have language support (through extensions) for primitive operations like splicing, and to have libraries that combine these operations into more complex systems (like automatic derivation of type classes).<br>
<br>&gt; Again, TH is very powerful, and fills in a number of holes in<br>&gt; Haskell&#39;s feature set. But it leaves me wondering if these holes<br>&gt; should not be filled in by other, more specialized features, leaving<br>
&gt; TH to continue to find other holes to fill.<br><br>Shouldn&#39;t specialized features be defined in terms of general features?<br><br>&gt;&gt; json :: String -&gt; JsonObject<br>&gt;&gt; json = ...<br>&gt;&gt;<br>&gt;&gt; data = [ json |<br>
&gt;&gt;    { &quot;name&quot; : &quot;Jonathan&quot;<br>&gt;&gt;    , &quot;favorite language&quot;: &quot;Haskell&quot;<br>&gt;&gt;    }<br>&gt;&gt;|]<br><br>How does this differ from the current QuasiQuotes extension? From what I can tell, all you need to achieve this with TH is to automatically derive a Language.Haskell.TH.Lift instance for JsonObject, i.e. a  function lift :: JsonObject -&gt; Q Exp such that the expression will evaluate to the original JsonObject. A QuasiQuoter like the one you describe can then be created by QuasiQuoter { parseExp = lift . json }. Should both approaches be supported directly, or should we sacrifice the generality of the current quoters for the simplicity of the ones you suggest?<br>
<br><br>The second part (deriving instances for general type classes) is a lot more complicated. I would say that the most general way of showing that a class can be derived is to provide a function that produces a set of declarations given the name of the datatype. Here&#39;s a very simple suggestion for incorporating this into the Haskell deriving syntax. Suppose we have these two classes and TH functions for deriving them:<br>
<br><span style="font-family: courier new,monospace;">class Class1 ...</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">class Class2 ...</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">class1 :: Name -&gt; Q [Dec]</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">class2 :: Name -&gt; Q [Dec]</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">data D = D deriving (Show,class1,class2)</span><br><br>The last declaration could expand to:<br><br><span style="font-family: courier new,monospace;">data D = D deriving Show</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">class1 &#39;D</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">class2 &#39;D</span><br><br>If you don&#39;t want to write class1 and class2 by operating directly on Haskell declarations, but rather use some DSL for specifying instances, then all you need is a function deriv :: DerivationDSL -&gt; (Name -&gt; Q [Dec]).<br>
<br>/J<br><br>On 27 December 2010 08:35, Jonathan Geddes &lt;<a href="mailto:geddes.jonathan@gmail.com">geddes.jonathan@gmail.com</a>&gt; wrote:<br>&gt; Cafe,<br>&gt;<br>&gt; First let me say that Template Haskell is very powerful and a lot of<br>
&gt; great work has been done in this area. It fills in a number of holes<br>&gt; in Haskell&#39;s feature set.<br>&gt;<br>&gt; But TH gives me the same feeling as other language features that have<br>&gt; been described as &quot;bolted on.&quot; Also, TH is both library and built-in<br>
&gt; syntax (via an extension) which feels strange to me. Finally, It&#39;s<br>&gt; very complicated to do some simple things.<br>&gt;<br>&gt; I see TH used most for the following tasks:<br>&gt;<br>&gt; #1 Parse a string at compile-time so that a custom syntax for<br>
&gt; representing data can be used. At the extreme, this &quot;data&quot; might even<br>&gt; be an EDSL.<br>&gt; #2 Provide instances automatically.<br>&gt;<br>&gt; I would propose that more specialized features be implemented to<br>
&gt; accomplish these tasks. To start, I&#39;ll throw out some ideas that<br>&gt; provide these capabilities.<br>&gt;<br>&gt; For TH use #1, compile-time parsing of arbitrary strings, I think it<br>&gt; would be nice for quasiquote semantics to be modified so that code<br>
&gt; like<br>&gt;<br>&gt;&gt; json :: String -&gt; JsonObject<br>&gt;&gt; json = ...<br>&gt;&gt;<br>&gt;&gt; data = [ json |<br>&gt;&gt;    { &quot;name&quot; : &quot;Jonathan&quot;<br>&gt;&gt;    , &quot;favorite language&quot;: &quot;Haskell&quot;<br>
&gt;&gt;    }<br>&gt;&gt;|]<br>&gt;<br>&gt; causes the function json to be called at compile time with a string<br>&gt; argument of &quot;   {\&quot;name\&quot; : \&quot;Jonathan\&quot;\n   , \&quot;favorite language\&quot;:<br>
&gt; \&quot;Haskell\&quot;\n   }&quot;. The whole expression being then replaced with the<br>&gt; result of the function application. What I like about this is that<br>&gt; defining &quot;quasiquoters&quot; is trivial. They&#39;re just functions of the form<br>
&gt; String -&gt; a. Many such quasiquoters already exist and would be ready<br>&gt; for use! I imagine certain rules would apply, ie a quasiquoter must be<br>&gt; defined prior to use and in a separate module, etc.<br>&gt;<br>
&gt; For TH use #2, automatic instances, I would propose a way of declaring<br>&gt; that a class can be automatically derived, and therefore added to the<br>&gt; set [Eq, Ord, Show, Read, ... , etc]. This is the set of classes that<br>
&gt; can be put in the &quot;deriving&quot; clause of a type declaration. I don&#39;t<br>&gt; know exactly what the syntax for this would look like, but I imagine<br>&gt; it would look a bit like the various current implementations of<br>
&gt; automatic instances in TH.<br>&gt;<br>&gt; Again, TH is very powerful, and fills in a number of holes in<br>&gt; Haskell&#39;s feature set. But it leaves me wondering if these holes<br>&gt; should not be filled in by other, more specialized features, leaving<br>
&gt; TH to continue to find other holes to fill.<br>&gt;<br>&gt; I&#39;m wondering if others see TH as a permanent solution, or if you<br>&gt; agree with me that some of TH&#39;s most common usages should have more<br>&gt; specialized features dedicated to them. It may very well be that I am<br>
&gt; simply not experienced enough with TH to fully appreciate and embrace<br>&gt; it.<br>&gt;<br>&gt; By the way, did I miss any uses of TH as common as the ones I mentioned?<br>&gt;<br>&gt; --Jonathan<br>&gt;<br>&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br><br>