Hi Adam,
> On 9 Feb 2015, at 17:44, Adam Gundry wrote:
> 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...
I was
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 wrote:
>> What does "all monomorphic cases" mean? Is the idea what GHC would
>> typecheck an expression involving a literal integer, determin
Hi Adam,
> On 6 Feb 2015, at 21:31, Adam Gundry 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 occu
Its worth pointing out that when / if luites out of process TH design
happens for ghc, TH will be usable in cross compile builds of ghc as well.
So we shouldn't let that constraint we have for now dictate future tooling
ideas.
On Feb 6, 2015 3:50 PM, "Evan Laforge" wrote:
> Would it be feasible t
Would it be feasible to make a lighter-weight mode for quasiquotes
that doesn't require the whole "load the module in ghci" runaround?
If it didn't need to do that, there wouldn't be much downside to
turning it on everywhere. And it would enable lots of QQ conveniences
that at least I don't think
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
pr
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
def
My greatest concern here would be that, as an application is maintained, a
literal might go from monomorphic to polymorphic, or vice versa, without
anybody noticing. It sounds like this could result in a value silently
becoming partial, which would be a big problem for application stability;
in th
Ryan,
Unfortunately, yes, you are understanding that correctly.
The reason I qualified it with "monomorphic only" is that, I want to avoid
breakage that would render the extension practically unusable in real code.
Let's say I right now have:
foo :: Num a => [a] -> [a]
foo = map (+1)
I have t
I think the idea of compile-time validation for overloaded literals is
fantastic, and doing it with nicer syntax than quasiquoting would really
improve things. However, I'm a bit confused about specifically how the
requirement that it be monomorphic will play into this. For example, if I
have:
x
While I am certainly in favour of better and more flexible approaches to
enforcing this in the type system (I'm a big fan of all the dependent
Haskell/singletons stuff), I don't think this is an appropriate solution here.
First off, a lot of interesting and important cases can't feasibly be solv
On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese
wrote:
> Agreed. For the idea to scale, good support for type-level
> programming with Integers/Strings/... is essential. Something else
> that would be useful is an unsatisfiable primitive constraint
> constructor `UnsatisfiableConstraint :: St
2015-02-06 14:20 GMT+01:00 Adam Gundry :
> It seems to me that what you would describe would work, and the
> avoidance of TH is a merit, but the downside is the complexity of
> implementing even relatively simple validation at the type level (as
> opposed to just reusing a term-level function). For
Hi Merijn,
2015-02-06 13:45 GMT+01:00 Merijn Verstraaten :
> I don't see how that would replace the usecase I describe?
I've written out the Even use case a bit, to hopefully clarify my
suggestion. The code is a bit cumbersome and inefficient because I
can't use GHC type-lits because some type-l
Hi Dominique,
On 06/02/15 12:13, Dominique Devriese wrote:
> Perhaps only for the sake of discussion: have you considered doing
> something at the type-level instead of using TH? I mean that you could
> change the type of 42 from `forall a. Num a => a` to `forall a.
> HasIntLiteral a '42 => a` whe
Hi Dominique,
I don't see how that would replace the usecase I describe? I'll give you a more
concrete example from a library I'm working on. I'm working on a Haskell
implementation of ZeroMQ, the ZMTP protocol lets sockets be named by a "binary
identifier with length <= 255 and NOT starting wi
Merijn,
Perhaps only for the sake of discussion: have you considered doing
something at the type-level instead of using TH? I mean that you could
change the type of 42 from `forall a. Num a => a` to `forall a.
HasIntLiteral a '42 => a` where HasIntegerLiteral is a type class of
kind `* -> 'Integer
And no one of my proofreaders noticed that >.>
I would propose to have the extension replace the 'fromString "foo"',
'fromIntegral 5' and 'fromList [1,2,3]' calls (for monomorphic cases) in the
AST with the relevant Typed TH splice.
I considered quasi-quotation initially too, but there's no qua
I'm all for it. Syntax sounds like the main difficulty. Today you could use
quasiquotatoin
[even| 38 |]
and get the same effect as $$(validate 38). But it's still noisy.
So: what is the non-noisy scheme you want to propose? You don't quite get to
that in the wiki page!
Simon
|
19 matches
Mail list logo