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
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
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 -
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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'
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
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
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)
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
27 matches
Mail list logo
