Sent: 05 September 2018 16:26
To: Ryan Scott
Cc: Simon Peyton Jones ; ghc-devs@haskell.org
Subject: Re: Unpacking coercions
I don't think that wiki reference is really about this problem.
Instead, I think that we'd need Constraint# to be able to offer users ~# and
~R#. The problem
type NomEq# = (~#)
>
> type ReprEq# = (~R#)
>
>
>
> Simon
>
>
>
> From: Ryan Scott mailto:ryan.gl.sc...@gmail.com>>
> Sent: 05 September 2018 15:26
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: ghc-devs@
t; now, it’ll surely come back.
>
>
>
> If that is lexically tiresome, we could I suppose provide builtin-aliases
> for them, as if we had
>
> type NomEq# = (~#)
>
> type ReprEq# = (~R#)
>
>
>
> Simon
>
>
>
> *From:* Ryan S
15:26
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Unpacking coercions
> Simple is good. But what is this dead simple idea?
I'm referring to David's first e-mail on this thread:
https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html
All that would t
nges. Making evidence strict would require
> no language changes to solve the original problem.
>
>
>
> Maybe this thread belongs with the proposal, unless I’m misunderstanding.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Ryan Scott
> *Se
to solve the original problem.
Maybe this thread belongs with the proposal, unless I’m misunderstanding.
Simon
From: ghc-devs On Behalf Of Ryan Scott
Sent: 05 September 2018 15:15
To: ghc-devs@haskell.org
Subject: Re: Unpacking coercions
These aren't mutually exclusive ideas. While I'm sure
These aren't mutually exclusive ideas. While I'm sure there's many ways we
could solve this problem, David's idea has the distinct advantage of being
dead simple. I'd rather not block his vision on some other large refactor
that may never materialize. (And if it _does_ materialize, we could revert
-devs@haskell.org
Subject: Re: Unpacking coercions
In case this wasn't clear, the context of this discussion in this GHC proposal
[1], where David is trying to work around the fact that data types with
existential Coercible constraints do not support unpacking. (By "unpacking", I
me
In case this wasn't clear, the context of this discussion in this GHC
proposal [1], where David is trying to work around the fact that data types
with existential Coercible constraints do not support unpacking. (By
"unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of
that
It would be good to have a clear problem statement, plus an example of a
program that runs more slowly than it “should”.
Simon
From: ghc-devs On Behalf Of Ryan Scott
Sent: 04 September 2018 14:02
To: ghc-devs@haskell.org
Subject: Re: Unpacking coercions
If we can gain some performance from
If we can gain some performance from this, then I'm generally supportive of
this idea.
I'm still of the belief that we could teach GHC to unpack boxed equality
constraints, but your idea would definitely be the simpler one to implement.
Ryan S.
___
I had an idea for how we might be able to unpack coercions in a limited and
conservative way that doesn't get into the general problems of unpacking
constraints. Would this make sense?
1. Move the definition of Coercion from Data.Type.Coercion to GHC.Magic
2. Magically change the type of the
12 matches
Mail list logo
