I remember Luite mentioning that when he and Ryan Yates where working out
STM for GHCJS, that they had found some bugs in STM in ghc (presumably now
fixed in head?), have you been able to reproduce the problem in head?
theres also some issues with STM relating to fairness, could you be hitting
a
Hi all,
I have a program that uses STM heavily and also performs lots of foreign
calls. I've noticed that sometimes the program uses 100% CPU indefinitely
and uses lots of memory - I see it go up to about 5GB before I kill it.
I've grabbed some preliminary samples of stack traces and see lots stm
If I understand correctly, the LNE-detection in CoreToSTG makes all of the
decisions; it's the only place that the StgLetNoEscape constructor arises.
Join-points are only implemented as LNE if they are detected to be LNE,
which they most often — but not always! — after all the core2core
simplifica
On Oct 16, 2013, at 4:23 PM, Simon Peyton-Jones wrote:
> What it would mean is that, if we do decide to generalize roles further,
> users would have one release that allows noticeably fewer uses of GND than
> the one before or the one after it. On the other hand, if we're confident
> that we'r
What it would mean is that, if we do decide to generalize roles further, users
would have one release that allows noticeably fewer uses of GND than the one
before or the one after it. On the other hand, if we're confident that we're
not going to tinker with roles more, then I see much stronger r
Hi,
Am Mittwoch, den 16.10.2013, 12:50 -0400 schrieb Edward Kmett:
> This does seem to me to have the ugly consequence of splitting the
> long term solutions for Coercible and GND, but I can fully understand
> the appeal of finally plugging the GND issue!
I don’t think the solutions are split up.
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
I think we're basically in agreement. I'm more than happy to write those 5-6
instances that legitimately aren't safe to derive.
-Edward
> On Oct 16, 2013, at 1:30 PM, Richard Eisenberg wrote:
>
> It seems like we may be on the same page now. Do you agree with my previous
> email that the chan
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
It seems like we may be on the same page now. Do you agree with my previous
email that the change to the GND check will not solve *all* your problems? That
is, there will be some derived instances you will have to hand-write, but (I
think) for good reason.
Richard
On Oct 16, 2013, at 12:46 PM,
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
If we can't find any major problems with the dictionary casting once it is
implemented, I'm fully on board.
This does seem to me to have the ugly consequence of splitting the long term
solutions for Coercible and GND, but I can fully understand the appeal of
finally plugging the GND issue!
-E
> On Oct 16, 2013, at 9:28 AM, Simon Peyton-Jones wrote:
>
> I think I know what to do about the GND + roles question.
>
> First, the problem. Here’s an example:
> class Trans t a where
> foo :: t a -> t a
>
> newtype N x = MkN x deriving( Trans Maybe )
>
> As things sta
Hi all,
I'm trying to understand this:
1. Note [What is a non-escaping let] says that one of conditions of binding
being a non-escaping
let is non-updatability.
2. My understanding is that a if a binding has at least one parameter it is
non-updatable, though
I suspect that converse does not
Will this work with the new iPhone 5 S (64 bit ARM)? I assume that
it will work by running in 32 bit mode (requiring both 64 and 32 bit
libs to be loaded), but I'm not sure...
Thanks,
Dominick
On Mon, Oct 14, 2013 at 3:48 PM, Luke Iannini wrote:
> Hi all,
>
> Just wanted to let you know I've f
| > Moreover, I'm very keen to give a simple, precise answer to the
| question
| > if s is coercible to t
| > when is (T s) coercible to (T t)
| > I propose that the answer is given by precisely T's roles. At the
| > moment I don't see why we would want to do anything more complicated.
|
I think I know what to do about the GND + roles question.
First, the problem. Here’s an example:
class Trans t a where
foo :: t a -> t a
newtype N x = MkN x deriving( Trans Maybe )
As things stand, Trans gets roles (representational, nominal). The second
parameter ‘a’ gets a
We have a constraint (a~b) that can appear in a type signature
f :: (a~b) => a -> b
We can also have a type-level equality function
type family Eq a b where
Eq a a = True
Eq a b = False
The type-level Boolean reflects the (a~b)
> Simon Peyton-Jones writes:
>
> | - (What I was hoping for but didn't get.)
> | No compiler flag to suppress creating selector functions.
> | This would have allowed records to be declared re-using the same
> | name;
> | but left it entirely to the developer as to how to access them.
> |
Hi Johan, all,
Thanks for the interest in OverloadedRecordFields! I've been meaning to
write a blog post on the current status, but you've beaten me to it. The
extension is essentially finished, modulo a few minor issues that I need
to work through, and should hit HEAD soon after 7.8 is cut. That
20 matches
Mail list logo
