Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ Instead I find my self writing manually code like myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hmm, as long as you provide a type signature, Haskell could do implicit wrapping as well. If I'm not mistaken, the compiler should be able to figure out what to do in this case: myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo = foo Sjoerd On Dec 3, 2009, at 11:07 AM, Joachim Breitner wrote: Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ Instead I find my self writing manually code like myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi,
Am Donnerstag, den 03.12.2009, 11:25 +0100 schrieb Sjoerd Visscher:
Hmm, as long as you provide a type signature, Haskell could do implicit
wrapping as well.
If I'm not mistaken, the compiler should be able to figure out what to do in
this case:
myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo
myfoo = foo
Maybe it should, but it does not:
$ cat test.hs
data Foo = Foo
newtype MyFoo = MyFoo { unMyFoo :: Foo }
foo :: Foo - (() - Foo) - Foo
foo Foo f = Foo
myfoo :: MyFoo - (() - MyFoo) - MyFoo
myfoo = foo
$ runhaskell test.hs
test.hs:9:8:
Couldn't match expected type `MyFoo' against inferred type `Foo'
In the expression: foo
In the definition of `myfoo': myfoo = foo
Greetings,
JOachim
--
Joachim Breitner
e-Mail: m...@joachim-breitner.de
Homepage: http://www.joachim-breitner.de
ICQ#: 74513189
Jabber-ID: nome...@joachim-breitner.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
I am uncertain if what any of you seek makes sense. The type checker is concerned with establishing a principle type and that is what is being reported, the principle type. The compiler as I pointed out in On the Meaning of Haskell 8 by design has not a clue as to the significance your type alias has.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. Yes, but what does Dual [1] `mappend Dual [2] mean then? Should it use the Monoid instance of Dual and return Dual [2, 1] ? Should it unwrap the lists beforehand and re-wrap them afterwards and return Dual [1, 2] ? Should it unwrap the resulting list afterwards and return [1, 2] or even [2,1] ? That's not obvious to me. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
In the case of Dual [1] `mappend` Dual [2] there's no need to do any unwrapping. There is if you say: l :: [Int] l = Dual [1] `mappend` Dual [2] The way I think this could work is that when the type checker detects a type error, it will first try to resolve it by newtype unwrapping (or wrapping even). Sjoerd On Dec 3, 2009, at 11:47 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. Yes, but what does Dual [1] `mappend Dual [2] mean then? Should it use the Monoid instance of Dual and return Dual [2, 1] ? Should it unwrap the lists beforehand and re-wrap them afterwards and return Dual [1, 2] ? Should it unwrap the resulting list afterwards and return [1, 2] or even [2,1] ? That's not obvious to me. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
Sjoerd Visscher wrote:
In the case of Dual [1] `mappend` Dual [2] there's no need to do any
unwrapping. There is if you say:
l :: [Int]
l = Dual [1] `mappend` Dual [2]
The way I think this could work is that when the type checker detects a type
error, it will first try to resolve it by newtype unwrapping (or wrapping even).
So if I have:
l :: Dual [Int]
l = [1] `mappend` [2]
It will wrap after the mappend, rather than before? But:
l :: Dual [Int]
l = Dual [1] `mappend` [2]
Would wrap the RHS in Dual? Does this version unwrap the LHS:
l :: [Int]
l = Dual [1] `mappend` [2]
And finally, what about:
l :: [Int]
l = Dual [1] `mappend` Endo [2]
Automatic wrapping and unwrapping, like automatic coercions, look like
an opportunity for surprising behaviour. OTOH, perhaps some sort of
deriving mechanism would be good. To revisit someone's previous
suggestion, perhaps you could allow functions in the deriving clause, so
that if you have:
f :: Foo - Foo - Foo
newtype MyFoo = MyFoo {getFoo :: Foo}
deriving (f as g)
will generate:
g :: MyFoo - MyFoo - MyFoo
g x y = Foo (f (getFoo x) (getFoo y))
I think it's not something worth adding (too subtle), but I thought I'd
throw it in as a possibility.
Neil.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo Matthew not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Of course, I meand 'deriving', not 'defining' /me embarsed 2009/12/3 Matthew Pocock matthew.poc...@ncl.ac.uk Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi Martijn On 3 Dec 2009, at 00:16, Martijn van Steenbergen wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? Subtyping. What advantages and disadvantages would it have? The typechecker being psychic; the fact that it isn't. It's very easy to add forms of subtyping and make a mess of type and instance inference. In what cases would this lead to ambiguous code? If f :: x - ZipList y we get traverse f :: t x - [t y] but it is not clear whether to attach the unpacking to f or to the result, and that will determine the idiom in which the traversal occurs. And that's before you start mixing the sugar of newtypes with the fertiliser of GADTs... But even if it's dangerous to unpack newtypes silently, it's rather nice to do it systematically, via a type class. Here are old posts of mine which mention this and then show off a bit. http://www.mail-archive.com/haskell-cafe@haskell.org/msg37213.html http://www.haskell.org/pipermail/libraries/2008-January/008917.html These days, how about class Newtype n where type Unpack n pack :: Unpack n - n unpack :: n - Unpack n and related machinery? Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
There is another point that needs to be made. A type signature isn't actually a type specification. It is a type assertion and a type specification in the event that the compiler needs your help. Most of the time the compiler can care less what you think and does not require your assistance. In languages like C you get to call the shots. In languages such as Haskell you don't get that opportunity.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Something like the restricted type synonym extension in Hugs? http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: http://www.haskell.org/pipermail/libraries/2008-January/008917.html On Tue, Jan 15, 2008 at 3:31 PM, Conor McBride wrote: Haskell's classes are the best damn rhythm section in the industry: you hum it, they play it. On Fri, Dec 10, 2004 at 2:21 AM, Conor McBride wrote: If you're willing to make the types distinguish the idioms you're using, as in choice-lists and vector-lists, then a lot of routine operations wither to a huddle of combinators sitting under a type signature which actually does most of the work. Instance inference is like having a great rhythm section: you hum it, they play it. Very eloquent Conor. Can we get this guy quoted in HWN? I think he's earned it. :-) On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: class Newtype n where type Unpack n pack :: Unpack n - n unpack :: n - Unpack n Nice. Would the code below be a good way to deal with subtyping? It'd be convenient to have some way to go from a 64-bit Double to a 32-bit Float and be informed when a Double can't be represented precisely by a Float, but to have the option to move forward with the minor loss of precision. class Subset n where type Superset n demote :: Superset n - Either n n promote :: n - Superset n squeeze :: Subset n = Superset n - n squeeze = either id id . demote In action: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13554#a13554 Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 13:03 -0500 schrieb David Menendez: On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner m...@joachim-breitner.de wrote: Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Something like the restricted type synonym extension in Hugs? http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html yes, this is very close to what I’d hope for. Last minor (but really minor) wish: I don’t think it would hurt to allow the use of this feature independent of the definition of the newtype: I could have a newtype Foo = Foo Int somewhere, possibly in a different module, and write something like myFoo :: Foo - (Foo,Foo) resolving Foo myFoo a = (a,a+a) (syntax and wording very ad hoc and not thought through). But yes, I think I’d be happy to have hugs’ extension here at hand sometimes. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Wed, Dec 2, 2009 at 7:16 PM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? As several have suggested, this creates ambiguity. But it might be handy to have a way to declare a scope in which the newtype is transparent. E.g., newtype N = N T f :: T - T - T f = ... open N in -- in this block, N is treated as a synonym for T g :: N - N - N g = f This is similar to the restricted type synonyms feature in Hugs, and I think it's straightforward to encode in GHC's System FC. From my perspective, the primary advantage to a feature like this is that it avoids the need to convert [N] to [T], which under the current system effectively requires mapping an identity function over the entire list. But that also exposes the danger of this idea, where GADTs and type families are involved. data G where A :: G N B :: G T a :: G N - N a ~A = N -- should never fail, because A is the only (non-bottom) value of type G N. Now, what stops me from writing something like this? open N in ... a B ... (See the discussion at http://hackage.haskell.org/trac/ghc/ticket/1496 for how this problem crops up with generalized newtype deriving.) -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Implicit newtype unwrapping
So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Isn't that the point of type-classes? Martijn van Steenbergen wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Out of curiosity, why would one want a newtype that were unwrapped implicitly, rather than just using type? Personally, whenever I use a newtype it is precisely because I *want* the compiler not to implicitly turn it into something else in order to protect myself. Cheers, Greg On Dec 2, 2009, at 4:16 PM, Martijn van Steenbergen wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Gregory Crosswhite gcr...@phys.washington.edu wrote: Out of curiosity, why would one want a newtype that were unwrapped implicitly, rather than just using type? One reason might be because you only switched from 'type' to 'newtype' so that you could write more refined Arbitrary instances for your QuickCheck tests. -Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Wed, Dec 2, 2009 at 6:08 PM, Greg Fitzgerald gari...@gmail.com wrote: Gregory Crosswhite gcr...@phys.washington.edu wrote: Out of curiosity, why would one want a newtype that were unwrapped implicitly, rather than just using type? One reason might be because you only switched from 'type' to 'newtype' so that you could write more refined Arbitrary instances for your QuickCheck tests. Maybe that is an indication that we should use a checker combinator library instead of typeclasses for automated testing. Less convenient, more adaptable. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Ah, that's a really good point. It seems then that there is a use for implicitly unwrapped newtypes, but perhaps only when you never really wanted to use a newtype to begin with but had to in order to use a different instance declaration for the same type. That suggests that the feature we'd really like is a way to declare that we want a type in a context to act as if it had a different instance declaration for a given typeclass, without having to go through newtype. Cheers, Greg On Dec 2, 2009, at 5:08 PM, Greg Fitzgerald wrote: Gregory Crosswhite gcr...@phys.washington.edu wrote: Out of curiosity, why would one want a newtype that were unwrapped implicitly, rather than just using type? One reason might be because you only switched from 'type' to 'newtype' so that you could write more refined Arbitrary instances for your QuickCheck tests. -Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
That suggests that the feature we'd really like is a way to declare that we want a type in a context to act as if it had a different instance declaration for a given typeclass, without having to go through newtype. I'd want implicit type coercion from subtypes, so that you wouldn't need an infinite hierarchy of nested typeclasses to implement the following for all integers: data One = One -- Somehow tell GHC that One is a subset of Integer (without implementing Num) oneToInteger :: One - Integer oneToInteger One = 1 One + One == (2 :: Integer) Seems like something Agda could handle. -Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
But it seems to me like the whole point of using newtype is because you *don't* want your new type to be used everywhere that the old type can be used; otherwise you would just use type to create an alias. The only convincing exception I have heard to this (as you helpfully explained to me) is that one might be forced to use newtype to make a piece of code use a different instance declaration for a type. In particular, I am not sure what you are getting at with your example, since one :: Integer one = 1 works just as well. Why did you want to define a new type? Cheers, Greg On Dec 2, 2009, at 6:40 PM, Greg Fitzgerald wrote: That suggests that the feature we'd really like is a way to declare that we want a type in a context to act as if it had a different instance declaration for a given typeclass, without having to go through newtype. I'd want implicit type coercion from subtypes, so that you wouldn't need an infinite hierarchy of nested typeclasses to implement the following for all integers: data One = One -- Somehow tell GHC that One is a subset of Integer (without implementing Num) oneToInteger :: One - Integer oneToInteger One = 1 One + One == (2 :: Integer) Seems like something Agda could handle. -Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
2009/12/3 Gregory Crosswhite gcr...@phys.washington.edu: But it seems to me like the whole point of using newtype is because you *don't* want your new type to be used everywhere that the old type can be used; otherwise you would just use type to create an alias. The only convincing exception I have heard to this (as you helpfully explained to me) is that one might be forced to use newtype to make a piece of code use a different instance declaration for a type. You might also be forced to use a newtype because you need to use it recursively - i.e. you need an alternative to equirecursive types. I hit this quite often when building datatype using fixpoints-of-a-functor and regularly wish for the ability to write: type Fix f = f (Fix f) Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
