Hi Adam,
On 9 Feb 2015, at 17:44, Adam Gundry a...@well-typed.com 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
Hi Adam,
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?
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
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
14:46
| To: ghc-d...@haskell.org; GHC users
| Subject: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
|
| I've been repeatedly running into problems with overloaded literals and
| partial conversion functions, so I wrote up an initial proposal
| (https://ghc.haskell.org/trac/ghc
| Sent: 05 February 2015 14:46
| To: ghc-d...@haskell.org; GHC users
| Subject: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
|
| I've been repeatedly running into problems with overloaded literals and
| partial conversion functions, so I wrote up an initial proposal
| (https
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:
: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
|
| I've been repeatedly running into problems with overloaded literals and
| partial conversion functions, so I wrote up an initial proposal
| (https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like
| to commence
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
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Merijn
| Verstraaten
| Sent: 05 February 2015 14:46
| To: ghc-d...@haskell.org; GHC users
| Subject: Proposal: ValidateMonoLiterals - Initial bikeshed discussion
|
| I've been repeatedly running
I've been repeatedly running into problems with overloaded literals and partial
conversion functions, so I wrote up an initial proposal
(https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like to
commence with the bikeshedding and hearing other opinions :)
Cheers,
Merijn
20 matches
Mail list logo
