If we go for a separate syntax, what do we gain over normal quasiquotes or $$(validate x)? Sure, literals could be made a little more beautiful, but I'm not sure it justifies stealing more syntax (and what would that syntax be?).
Without a separate syntax, I'm not sure I understand the original proposal. The wiki page says "GHC would replace fromString/fromInteger/fromList expressions originating from literals with a Typed TH splice along the lines of validate for all monomorphic cases." 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? None of this is particularly persuasive, I'm afraid. Is it worthwhile introducing something new just to avoid having to write a quasiquote? I *am* attracted to the idea of indexed classes in place of IsString/Num class KnownSymbol s => IsIndexedString (a :: *) (s :: Symbol) where fromIndexedString :: a class KnownInteger i => IsIndexedInteger (a :: *) (i :: Integer) where fromIndexedInteger :: a These have a smooth upgrade path from the existing class instances via default fromIndexedString :: (KnownSymbol s, IsString a) => a fromIndexedString = fromString (symbolVal (Proxy :: Proxy s)) default fromIndexedInteger :: (KnownInteger i, Num a) => a fromIndexedInteger = fromInteger (integerVal (Proxy :: Proxy i)) and other instances can take advantage of the additional type information. perhaps we need to bring Dependent Haskell a bit closer before this is justifiable... Adam On 06/02/15 17:24, Dan Doel wrote: > Assuming a separate syntax, I believe that the criterion would be as > simple as ensuring that no ValidateFoo constraints are left outstanding. > The syntax would add the relevant validate call, and type variables > involved in a ValidateFoo constraint would not be generalizable, and > would have to be defaulted or inferred from elsewhere, similar to the > monomorphism restriction. I'm not sure how difficult that would be to > implement. > > I'm not terribly gung ho on this, though. It feels very ad hoc. Making > validation vs. non-validation syntactic rather than just based on > polymorphism seems somewhat less so, though; so I'd prefer that > direction. Finding unused syntax is always a problem, of course. -- 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