On Tue, Jan 22, 2013 at 7:41 AM, wren ng thornton 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 Sun, Jan 20, 2013 at 8:13 PM, wren ng thornton 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 maps
> are some
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 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. Could
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'
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 thing
uot;. The "Internals" module name convention is a signal that you must
be particularly careful when importing this module; 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
On Tue, Jan 15, 2013 at 3:15 AM, Iavor Diatchki
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, consider:
>
> newtype T
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 b
Looks great; I care and have no improvements to offer; +1 from me.
Chris
From: Simon Peyton-Jones
Date: Monday, 14 January 2013 18:09
To: glasgow-haskell-users
Subject: Newtype wrappers
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 wrote:
> On Mon, Jan 14, 2013 at 3:40 PM, Evan Laforge wrote:
>> Wait, what's the runtime error? Do you mean messing
On Mon, Jan 14, 2013 at 09:03:38PM +0200, Roman Cheplyaka wrote:
> * Simon Peyton-Jones [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/Newtype
On Mon, Jan 14, 2013 at 5:29 PM, Johan Tibell wrote:
> 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 or not?
If y
On Mon, Jan 14, 2013 at 3:40 PM, Evan Laforge 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,
> even with newtype
On Mon, Jan 14, 2013 at 03:28:15PM -0800, Johan Tibell wrote:
> On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge 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 '
On Mon, Jan 14, 2013 at 3:28 PM, Johan Tibell wrote:
> On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge 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 ...
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge 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 and coerces
* Johan Tibell [2013-01-14 15:11:25-0800]
> On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka 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
-Jones > 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?
>>
>
On Mon, Jan 14, 2013 at 3:11 PM, Johan Tibell wrote:
> On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka 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 in
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka 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 thread. Simon'
* Johan Tibell [2013-01-14 14:55:31-0800]
> On Mon, Jan 14, 2013 at 2:33 PM, Roman Cheplyaka wrote:
> > * Johan Tibell [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 =
On Mon, Jan 14, 2013 at 2:33 PM, Roman Cheplyaka wrote:
> * Johan Tibell [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 xs
>>
>> behave differently
6, 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
* Johan Tibell [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 xs
>
> behave differently if the constructors of Map are in scope or not?
Coercion is ne
On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka wrote:
> * Johan Tibell [2013-01-14 13:32:54-0800]
>> On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
>> wrote:
>> > Have you considered the effect on types like Data.Set that use the
>> > uniqueness of typeclass instances to maintain invarian
* Johan Tibell [2013-01-14 13:32:54-0800]
> On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
> 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
On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
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 wrong sha
ntains the abstraction as indeed it
should.
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
mailto:simo...@microsoft.com>> wrote:
Frien
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 “is a
On 1/14/13 2:42 PM, Johan Tibell wrote:
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi 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 p
Hello,
On Mon, Jan 14, 2013 at 8:14 PM, Andrea Vezzosi 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 wro
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 p
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi 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 wrong shape
On Mon, Jan 14, 2013 at 7: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
* Simon Peyton-Jones [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 'coerce'?
B
Simon Peyton-Jones 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 unsafeCoerce accomp
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 tha
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 comme
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 ca
41 matches
Mail list logo
