Hi Merijn, Thanks for persevering with explaining things to me. :-)
On 09/02/15 09:47, Merijn Verstraaten wrote: >> On 6 Feb 2015, at 21:31, Adam Gundry <a...@well-typed.com> wrote: >> What does "all monomorphic cases" mean? Is the idea what GHC would >> typecheck an expression involving a literal integer, determine that >> the occurrence had type Even, then evaluate the TH splice *after* >> typechecking? Whereas if the occurrence had a non-ground type, it >> would do something else? > > Yes, Typed TH already runs *after* type checking, which is what > allows you to do validation based on the resulting type. The main > reason why I was only proposing to do this for monomorphic values is, > because, how could you possible validate a polymorphic literal? Which > validation function would you use? > > You could ban polymorphic literals, but that'd involve eliminating > most uses of polymorphic Num functions (as I mentioned as another > email), which would break so much code it would render the extension > unusable in "real" code. I'm open to better ideas on how to tackle > this, the main reason I started this discussion is because I don't > really like this "polymorphic literals fail at compile time" thing > either. I just don't see how to solve it without going all dependent > types on the problem. In the absence of a coherent story for polymorphism, I think the right thing to do is to be able to specify a particular validator, rather than try to have type inference determine a monomorphic type and otherwise get stuck... >> None of this is particularly persuasive, I'm afraid. Is it >> worthwhile introducing something new just to avoid having to write >> a quasi quote? > > Actually, I would be mildly ok with quasi quoters, BUT there > currently is no Typed TH quasi quoter (as mentioned on the wiki > page), additionally, such a quoter does not have access to Lift > instances for all but a handful of datatypes until we have a more > comprehensive way to generate Lift instances. I think both of these > points are also highly relevant for this dicussion. ...so is the right solution to introduce Typed TH quasiquoters for expressions? Sorry, I presumed such a thing existed, as Typed TH is rather regrettably underdocumented. Is there any particular difficulty with them, or is it just a Small Matter of Programming? I think the lack of Lift instances is a separate problem; while it looks like 7.10 will be better in this respect and dataToExpQ goes a fair way, I agree that making them easier to generate would be nice. Perhaps a generics-based default method combined with DeriveAnyClass would make "deriving Lift" possible? Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users