On Tue, Jan 22, 2013 at 7:41 AM, wren ng thornton w...@freegeek.org wrote:
On 1/21/13 1:40 AM, Shachaf Ben-Kiki wrote:
For example:
{-# LANGUAGE TypeFamilies #-}
import Unsafe.Coerce
newtype Id a = MkId { unId :: a }
{-# RULES fmap unId fmap unId = unsafeCoerce #-}
On 1/21/13 1:40 AM, Shachaf Ben-Kiki wrote:
For example:
{-# LANGUAGE TypeFamilies #-}
import Unsafe.Coerce
newtype Id a = MkId { unId :: a }
{-# RULES fmap unId fmap unId = unsafeCoerce #-}
data family Foo x y a
data instance Foo x y (Id a) = FooI x
data
On 1/14/13 1:09 PM, Simon Peyton-Jones wrote:
Friends
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
Any comments? Below is the problem statement, taken from the above page.
I'd
On 1/14/13 2:47 PM, Stephen Paul Weber wrote:
Somebody claiming to be Simon Peyton-Jones wrote:
* For x1 we can write map MkAge x1 :: [Age]. But this does not
follow the newtype cost model: there will be runtime overhead from
executing the map at runtime, and sharing will be lost too.
On 1/14/13 9:15 PM, Iavor Diatchki wrote:
It looks like what we need is a different concept: one that talks about the
equality of the representations of types, rather then equality of the types
themselves.
+1.
In fact, this distinction is one of the crucial ones I had in mind when
working on
On Sun, Jan 20, 2013 at 8:13 PM, wren ng thornton w...@freegeek.org wrote:
I care. So far I've gotten around some of the problems by defining rewrite
rules which take (fmap NT), (fmap unNT), etc into unsafeCoerce. I haven't
run into the eta problems that I'm aware of, but the non-constant-time
On Tue, Jan 15, 2013 at 3:15 AM, Iavor Diatchki
iavor.diatc...@gmail.com wrote:
In general, I was never comfortable with GHC's choice to add an axiom
equating a newtype and its representation type, because it looks unsound to
me (without any type-functions or newtype deriving).
For example,
; runtime errors may result
if you screw up.
One possible conclusion: if we have them at all, newtype wrappers should only
work if you can see the constructors of *both* the newtype, *and* the type you
are lifting over.
But that's not very satisfactory either.
* There are some times (like IO
Hi,
Am Montag, den 14.01.2013, 18:09 + schrieb Simon Peyton-Jones:
I’d appreciate
·A sense of whether you care. Does this matter?
·Improvements to the design I propose
I do care (but that is no news, given my pestering on #2110 :-)) and
obviously I am happy that things
Friends
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
Any comments? Below is the problem statement, taken from the above page.
I'd appreciate
* A sense of whether you
Somebody claiming to be Simon Peyton-Jones wrote:
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
The high-level idea, I love. I always wondered about `map MkAge blah`.
Any
Many of us definitely care. =)
The main concern that I would have is that the existing solutions to this
problem could be implemented while retaining SafeHaskell, and I don't see
how a library that uses this can ever recover its SafeHaskell guarantee.
Here is a straw man example of a solution
Simon Peyton-Jones simo...@microsoft.com writes:
[...]
x1 :: [Int]
x2 :: Char - Int
x3 :: T Int
x4 :: S IO Int
Can we convert these into the corresponding forms where the Int is
replaced by Age? Alas, not easily, and certainly not without overhead
Maybe a stupid question: Can
* Simon Peyton-Jones simo...@microsoft.com [2013-01-14 18:09:50+]
Friends
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
Any comments?
Why not just have a pseudo-function
On Mon, Jan 14, 2013 at 7:09 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Friends
** **
I’d like to propose a way to “promote” newtypes over their enclosing
type. Here’s the writeup
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
** **
Any
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi sanzhi...@gmail.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
have newtype X = X Y coercing Set X to Set Y can produce a tree with
the
Somebody claiming to be Simon Peyton-Jones wrote:
* For x1 we can write map MkAge x1 :: [Age]. But this does not follow
the newtype cost model: there will be runtime overhead from executing the
map at runtime, and sharing will be lost too. Could GHC optimise the map
somehow?
My friend
Hello,
On Mon, Jan 14, 2013 at 8:14 PM, Andrea Vezzosi sanzhi...@gmail.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
have newtype X = X Y coercing Set X to Set Y can produce a tree with
On 1/14/13 2:42 PM, Johan Tibell wrote:
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi sanzhi...@gmail.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
have newtype X = X Y coercing Set X
If you are worrying about #1496, don’t worry; we must fix that, and the fix
will apply to newtype wrappers.
If you are worrying about something else, can you articulate what the something
else is?
I don’t want to involve type classes, nor Functor. We don’t even have a good
way to say
.
Simon
From: Andrea Vezzosi [mailto:sanzhi...@gmail.com]
Sent: 14 January 2013 19:15
To: Simon Peyton-Jones
Cc: GHC users
Subject: Re: Newtype wrappers
On Mon, Jan 14, 2013 at 7:09 PM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
Friends
I'd like to propose a way
On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
have newtype X = X Y coercing Set X to Set Y can produce a tree with
* Johan Tibell johan.tib...@gmail.com [2013-01-14 13:32:54-0800]
On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Have you considered the effect on types like Data.Set that use the
uniqueness of typeclass instances to maintain invariants? e.g. even when we
On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2013-01-14 13:32:54-0800]
On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Have you considered the effect on types like Data.Set that use the
are worrying about #1496, don’t worry; we must fix that, and the
fix will apply to newtype wrappers.
If you are worrying about something else, can you articulate what the
something else is?
** **
I don’t want to involve type classes, nor Functor. We don’t even have a
good way to say
On Mon, Jan 14, 2013 at 2:33 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2013-01-14 14:29:57-0800]
Let me rephrase: how will Simon's proposed data constructors are in
scope mechanism work? For example, will
let xs :: Map = ...
in map MyNewtype
* Johan Tibell johan.tib...@gmail.com [2013-01-14 14:55:31-0800]
On Mon, Jan 14, 2013 at 2:33 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2013-01-14 14:29:57-0800]
Let me rephrase: how will Simon's proposed data constructors are in
scope mechanism
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka r...@ro-che.info wrote:
It's described here:
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
We seem to be talking past each other. There's a specific problem
related to type classes and invariants on data types mentioned earlier
on this
On Mon, Jan 14, 2013 at 3:11 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka r...@ro-che.info wrote:
It's described here:
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
We seem to be talking past each other. There's a specific problem
...@microsoft.com
wrote:
If you are worrying about #1496, don’t worry; we must fix that, and the
fix will apply to newtype wrappers.
If you are worrying about something else, can you articulate what the
something else is?
** **
I don’t want to involve type classes, nor Functor. We don’t
* Johan Tibell johan.tib...@gmail.com [2013-01-14 15:11:25-0800]
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka r...@ro-che.info wrote:
It's described here:
http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers
We seem to be talking past each other. There's a specific problem
related
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote:
I assume it would change from doesn't compile to works if you add
the required import. It's the same as the FFI thing, right? If you
don't import M (T(..)), then 'foreign ... :: T - IO ()' gives an
error, but import it
On Mon, Jan 14, 2013 at 3:28 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote:
I assume it would change from doesn't compile to works if you add
the required import. It's the same as the FFI thing, right? If you
don't import
On Mon, Jan 14, 2013 at 03:28:15PM -0800, Johan Tibell wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote:
I assume it would change from doesn't compile to works if you add
the required import. It's the same as the FFI thing, right? If you
don't import M (T(..)),
On Mon, Jan 14, 2013 at 3:40 PM, Evan Laforge qdun...@gmail.com wrote:
Wait, what's the runtime error? Do you mean messing up Set's invariants?
Yes.
If you as the library writer don't want to allow unsafe things, then
don't export the constructor. Then no one can break your invariants,
On Mon, Jan 14, 2013 at 5:29 PM, Johan Tibell johan.tib...@gmail.comwrote:
Let me rephrase: how will Simon's proposed data constructors are in
scope mechanism work? For example, will
let xs :: Map = ...
in map MyNewtype xs
behave differently if the constructors of Map are in scope
On Mon, Jan 14, 2013 at 09:03:38PM +0200, Roman Cheplyaka wrote:
* Simon Peyton-Jones simo...@microsoft.com [2013-01-14 18:09:50+]
Friends
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
No magic coercing is present in the proposal. You need to use explicit newtype
wrap and newtype unwrap expressions.
Sent from my iPad
On Jan 14, 2013, at 6:42 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 14, 2013 at 3:40 PM, Evan Laforge qdun...@gmail.com wrote:
Wait, what's
Looks great; I care and have no improvements to offer; +1 from me.
Chris
From: Simon Peyton-Jones simo...@microsoft.com
Date: Monday, 14 January 2013 18:09
To: glasgow-haskell-users glasgow-haskell-users@haskell.org
Subject: Newtype wrappers
Friends
I¹d like to propose a way to ³promote
Hello,
The general functionality for this seems useful, but we should be careful
exactly what types we allow in the 'newtype wrap/unwrap' declarations. For
example, would we allow something like this:
newtype wrap cvt :: f a - f (Dual a)
If we just worry about what's in scope, then it should
40 matches
Mail list logo
