Correct. With 7.8 we'll need to hand-implement those instances rather than
derive them.
On Sat, Dec 14, 2013 at 7:59 PM, Ben Gamari wrote:
> Richard Eisenberg writes:
>
> > Yes, I believe that's right. As far as I can figure out, these classes
> > really *are* problematic, in that if we allowe
On Dec 14, 2013, at 7:59 PM, Ben Gamari wrote:
>
> I suppose it's unlikely that the roles mechanism will be extended to
> allow for such restriction?
Very unlikely in the short term. As more use cases for such a feature filter in
and the community demands the feature, there's no strong technic
Richard Eisenberg writes:
> Yes, I believe that's right. As far as I can figure out, these classes
> really *are* problematic, in that if we allowed
> GeneralizedNewtypeDeriving for them, there would be a way to subvert
> the type system. To make these derivable, we would need to be able to
> res
Yes, I believe that's right. As far as I can figure out, these classes really
*are* problematic, in that if we allowed GeneralizedNewtypeDeriving for them,
there would be a way to subvert the type system. To make these derivable, we
would need to be able to restrict various type parameters from
Edward Kmett writes:
> If this forced me to write those instances by hand, I could accept
> that as a tax for correctness. It means you can't GND any of the
> HasFoo dictionaries that lens builds, but meh.
>
Am I correct in assuming that Bind, R1, R2, R3, and R4 are the
problematic instances in l
Bah^2.
This is subtler than I thought.
See the ticket commentary here: http://ghc.haskell.org/trac/ghc/ticket/8503
Richard
On Nov 4, 2013, at 11:02 AM, Richard Eisenberg wrote:
> Bah. This is a bug. I will fix.
>
> Thanks for pointing it out!
> Richard
>
> On Nov 4, 2013, at 10:37 AM, Roman
Bah. This is a bug. I will fix.
Thanks for pointing it out!
Richard
On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka wrote:
> * Richard Eisenberg [2013-10-16 13:28:54-0400]
>>> Moreover, I think this solves the other failures in
>>> http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.ht
* Richard Eisenberg [2013-10-16 13:28:54-0400]
> > Moreover, I think this solves the other failures in
> > http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html. Here
> > is one example, in that email. smallcheck has this:
> > newtype Series m a = Series (ReaderT Depth (LogicT m)
ithin the next week, probably starting tomorrow,
and possibly ending tomorrow, too. Not sure exactly how hard it will be.
Richard
>
> Simon
>
> From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
> Sent: 16 October 2013 18:29
> To: Simon Peyton-Jones
> Cc: Edward Kmett;
fixed at the moment? Are you able to implement the new
GND check soon? Or not?
Simon
From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
Sent: 16 October 2013 18:29
To: Simon Peyton-Jones
Cc: Edward Kmett; ghc-devs
Subject: Re: More GND + role inference woes
Please see my responses below.
On Oct 16, 2013, at 1:46 PM, Edward Kmett wrote:
> Off the top of your head do things like the following work under the new
> scheme?
>
> newtype T m a = T { runT :: StateT MyState m a } deriving (Monad, MonadState
> MyState, MonadTrans)
>
Yes, I believe that will work. The only "hard" part
d see if I can't find a way to subvert the system, but
>> this sounds promising for roles.
>>
>> In light of this, the NPR approach that Richard suggested strikes me as more
>> relevant to fixing up Coercible than GND and as you mentioned we can very
>>
If this forced me to write those instances by hand, I could accept that as a
tax for correctness. It means you can't GND any of the HasFoo dictionaries that
lens builds, but meh.
My original objection was for the existing solution with type classes
themselves having their arguments be represent
the dictionary casts work the way we expect, I'm think I'm sold. The
> main thing I don't want to do is wake up after 7.8 is cut and personally have
> to write 4000 lines of previously derived instances that are provably safe,
> because of an overly restrictive role sche
Please see my responses below. (Note: this was written before Edward's most
recent post, which will be addressed shortly.)
Executive summary: Edward's problem is more general than the one that Simon
solves, but what Edward wants is actually not type safe.
On Oct 16, 2013, at 9:28 AM, Simon Peyto
#x27;t want to do is wake up after 7.8 is cut and personally have
to write 4000 lines of previously derived instances that are provably safe,
because of an overly restrictive role scheme. I'm cautiously optimistic that
this will be sufficient to keep me out of that scenario. ;)
-Edward
&
we are fine, once Richard has implemented the new GND test.
Am I wrong?
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward Kmett
Sent: 13 October 2013 23:02
To: ghc-devs; Richard Eisenberg
Subject: Re: More GND + role inference woes
I didn't think I was usi
Yuck.
But, many, many thanks for discovering this now instead of later.
For various silly reasons, I didn't have a platform (i.e. a recent enough HEAD
in the right state, etc.) for me to explore this today (Monday). But, I should
have the time and ability to look closer on Tuesday.
If it's rea
I didn't think I was using GND much at all, but apparently I was wrong.
After Ben's initial foray into building linear, I went and looked at the
other applications of GeneralizedNewtypeDeriving in my code and found that
in parsers, all of the derived instances for the supplied parser
transformers
Ben Gamari was trying to update my linear package to work with GHC HEAD.
Along the way he noted an example of the new GND+role inference machinery
failing rather spectacularly.
http://hackage.haskell.org/package/linear-1.3/docs/src/Linear-Affine.html#Point
Note the number of classes that the cur
20 matches
Mail list logo
