On Wed, Dec 2, 2009 at 7: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?
As several have suggested, this creates ambiguity.
But it might be handy to have a way to declare a scope in which the
newtype
Hi,
Am Donnerstag, den 03.12.2009, 13:03 -0500 schrieb David Menendez:
> On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner
> wrote:
> > Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock:
> >> Perhaps what you are looking for is a more powerful "defining"
> >> semantics?
> >>
> >> n
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
On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner
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 a
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
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
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
Of course, I meand 'deriving', not 'defining'
/me embarsed
2009/12/3 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
>
___
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 d
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
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
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
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 al
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) -> My
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 B
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
2009/12/3 Gregory Crosswhite :
> 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
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
> 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
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 r
On Wed, Dec 2, 2009 at 6:08 PM, Greg Fitzgerald wrote:
> Gregory Crosswhite 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
Gregory Crosswhite 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.
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, 2
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.
>>
>>
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)
instan
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,
>
> Ma
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
Hask
27 matches
Mail list logo