Proposal: ValidateMonoLiterals - Initial bikeshed discussion

[Adam Gundry]

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/