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
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 qdun...@gmail.com wrote:
Would
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
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 quasi
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 -
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
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:
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
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` where
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
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
Hi Merijn,
2015-02-06 13:45 GMT+01:00 Merijn Verstraaten mer...@inconsistent.nl:
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
2015-02-06 14:20 GMT+01:00 Adam Gundry a...@well-typed.com:
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
On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be 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
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 two
15 matches
Mail list logo
