<div dir="ltr">My "hidden agenda" is to liberate the SBV library to work on Haskell programs directly. (<a href="http://hackage.haskell.org/package/sbv">http://hackage.haskell.org/package/sbv</a>)<br><div><br></div><div>SBV allows programming with symbolic values, allowing a certain class of "proofs" to be done. It uses SMT solvers to do the actual "solving." It's limited in what it can do so far as reasoning goes: It's mostly limited to number types really (Word/Int/Float/Double etc.), but when it works, it really can be effective. Right now, users of this library have to write things like this:</div><div><br></div><div>   foo x y = ite (x .> y) (x+2) (x .< y)</div><div><br></div><div>Since I "cannot" reliably steal if-then-else (yes, I'm aware of RebindableSyntax; but it has its own problems.), nor I can just use comparison operators that insist on returning Bool that I cannot change. But those are smaller problems: The bigger issue is that I cannot support "case" expressions, pattern-matching, and all that stuff; since all that mechanism is baked into the compiler and I've no way to arrange for a pattern to "symbolically" match. This latter issue with pattern-matching and lack of support for case-expressions is why the library is sort of "hard-to-use" for a newcomer.</div><div><br></div><div>I tried TH/HSE before to see if I can let users write regular-Haskell and have the expressions automatically made "symbolic" aware, but ran into a lot of accidental complexity due to the extremely rich surface syntax. I'm currently working on a plugin to do the same, which is much nicer to work with; though you are correct that dealing with explicitly-typed core has its complexities as well. However, I do find it to be much easier to work with as compared to surface Haskell.</div><div><br></div><div>I suspect you guys went down to the "stand-alone" route with LiquidHaskell when you had similar problems. That definitely is a great approach as well, though I don't have the luxury of an academic research team to pursue that line of thought. (LiquidHaskell rocks by the way; I'm a real fan.)</div><div><br></div><div>-Levent.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 3:13 PM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 11, 2015, at 14:54, Levent Erkok wrote:<br>
> Spot on.. I really want "Template Core," independent of TH.<br>
><br>
> To be honest, "GHC Plugins" already provides "Template Core" in this<br>
> sense;<br>
> but would be nicer if one can get his hands on the Core in the regular<br>
> Haskell context, not just in a plugin context. So, perhaps "Template<br>
> Core"<br>
> is not the biggest priority in the big scheme of things.<br>
<br>
</span>I would caution against going the Core Plugin (or Template Core) route<br>
unless you really need to work with Core, e.g. if you're doing some sort<br>
of analysis and want to save your sanity by avoiding all of the surface<br>
syntax.<br>
<br>
Constructing and manipulating Core is quite tedious because Core is<br>
explicitly typed. This means that you have to instantiate type<br>
parameters of polymorphic functions/constructors yourself, and worse,<br>
you have to provide type-class dictionaries yourself. It's not<br>
impossible by any means, just a lot more work in my experience than<br>
working with surface syntax and letting GHC handle the rest :)<br>
<br>
I'm curious though, what specifically were you trying to use TH/HSE for<br>
in the past, analysis or code-generation?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>