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
Actually upon reflection, this does appear to help with implementing some
things in my code with a much reduced unsafeCoerce count, though it remains
orthogonal to the issue of how to lift these things through third-party
types that I raised above.
-Edward
On Mon, Jan 14, 2013 at 5:40 PM, Edward
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
It sounds like the solution you are proposing then is to an issue largely
orthogonal to the one I'm talking about.
As far as I can tell, I derive no immediate benefit from this version.
-Edward
On Mon, Jan 14, 2013 at 4:09 PM, Simon Peyton-Jones
wrote:
> If you are worrying about #1496, don’t
* 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
Oh! Is the definition of 'foo' rejected in recent versions of GHC? My 7.4.1
installation doesn't complain. -- Conal
Yes, it is rejected.
Simon
From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of
Conal Elliott
Sent: 14 January 2013 20:52
To: Simon Peyton-Jones
Cc: Rich
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
for the Ord instance of Y.
Good point. I should add this. Th
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 fu
On Mon, Jan 14, 2013 at 3:39 AM, Simon Peyton-Jones
wrote:
> There is a real difficulty here with type-checking 'bar'. (And that
> difficulty is why 'foo' is also rejected.)
This seems, to me, like a somewhat round-about way to express the
problem. Iavor's explanation (which approach I have als
Thanks, Jake! This suggestion helped a lot. -- Conal
On Sun, Jan 13, 2013 at 1:59 PM, Jake McArthur wrote:
> I have a trick that loses a little convenience, but may still be more
> convenient than data families.
>
> {-# LANGUAGE TypeFamilies #-}
>
> import Data.Tagged
>
> type family F a
>
> fo
>
> There is a real difficulty here with type-checking 'bar'. (And that
> difficulty is why 'foo' is also rejected.)
Oh! Is the definition of 'foo' rejected in recent versions of GHC? My 7.4.1
installation doesn't complain. -- Conal
On Mon, Jan 14, 2013 at 3:39 AM, Simon Peyton-Jones
wrote:
On 01/14/13 08:49 PM, Austin Seipp wrote:
Very true. It would be very nice if we could handle this issue
automatically after we figure out the proper way to handle it manually.
I think Karel is right that we may be able to get 90% of the way there
with a short hack in DriverPipeline, with some
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
(CC'ing glasgow-haskell-users, as it got lost somehow. A message or
two from me and Karel are also missing the list.)
On Mon, Jan 14, 2013 at 1:27 PM, Ben Gamari wrote:
> Austin Seipp writes:
>
>> I've been working on ARM the past weekend. Here's where I'm at
>> (semi-long email ahead.)
>>
> I'v
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
On 01/14/13 06:15 PM, Nathan Hüsken wrote:
In a different thread (Error building ghc on raspberry pi):
On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
I did eventually finish building stage2, but the final executable
segfaulted on start.
I haven't investigated much why that happened, the
hi nathan,
On Jan 14, 2013, at 6:15 PM, Nathan Hüsken wrote:
> Did anyone succesfully build ghc on an arm system which produces non
> crashing executables?
>
> I am asking, because I build a arm-linux-androideabi cross compiler, but
> the executables crash.
> Only in an unregisterised build, the
In a different thread (Error building ghc on raspberry pi):
On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
>
> I did eventually finish building stage2, but the final executable
segfaulted on start.
> I haven't investigated much why that happened, the days it takes to
rebuild it just
> made me
Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven:
> On Thu, 10 Jan 2013, Karel Gardas wrote:
>
>>
>> Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of
>> ARMv6/ARM11 chip here...
>>
>> I'm afraid LLVM is not well guided in your case so could
On Thu, 10 Jan 2013, Karel Gardas wrote:
Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of
ARMv6/ARM11 chip here...
I'm afraid LLVM is not well guided in your case so could you be so kind and
test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.
Hi,
I cannot push any patch to the time submodule of the GHC repo. For
instance, creating
a new branch succeeds locally, and succeeds in pushing, but the branch is
never created
on the remote. Also, no commit email is generated. Could this be fixed?
Thanks,
Pedro
| > > {-# LANGUAGE TypeFamilies #-}
| > >
| > > type family F a
| > >
| > > foo :: F a
| > > foo = undefined
| > >
| > > bar :: F a
| > > bar = foo
There is a real difficulty here with type-checking 'bar'. (And that difficulty
is why 'foo' is also rejected.)
Namely, when typechecking 'bar', we
45 matches
Mail list logo
