Hello Taral,
Tuesday, August 15, 2006, 3:11:37 AM, you wrote:
>> > Do we complain about a duplicate instance declarations?
>>
>> yes. after all, this is just syntax sugar of giving both declarations:
> Not necessarily. If A doesn't have any Functor declarations, it could
> be considered just a M
Hello Duncan,
Tuesday, August 15, 2006, 2:37:50 AM, you wrote:
> If it goes in that direction it'd be nice to consider the issue of
> structures which cannot support a polymorphic map. Of course such
> specialised containers (eg unboxed arrays or strings) are not functors
> but they are still use
Hello Donald,
Tuesday, August 15, 2006, 8:23:51 AM, you wrote:
> I just want to express that I really would like to see this. I was coding a
> DNS server in Haskell and the main reason I stopped was because binary IO was
> very, very painful (so many different library, or half libraries, whenever
While we're thinking a little about the libraries, I received the
following:
- Forwarded message from Pupeno <[EMAIL PROTECTED]> -
Date: Tue, 8 Aug 2006 07:44:04 +
Subject: Binary IO
Hello,
I've seen that you have been assigned the task of evaluating binary IO for
inclusion in Hask
On Mon, 2006-08-14 at 20:55 +0100, Jon Fairbairn wrote:
> On 2006-08-14 at 12:00PDT "Iavor Diatchki" wrote:
> > Hello,
> > I never liked the decision to rename 'map' to 'fmap', because it
> > introduces two different names for the same thing (and I find the name
> > `fmap' awkward).
>
> I strongly
On Aug 14, 2006, at 3:00 PM, Iavor Diatchki wrote:
Hello,
I never liked the decision to rename 'map' to 'fmap', because it
introduces two different names for the same thing (and I find the name
`fmap' awkward).
As far as I understand, this was done to make it easier to learn
Haskell, by turnin
On 2006-08-14 at 12:00PDT "Iavor Diatchki" wrote:
> Hello,
> I never liked the decision to rename 'map' to 'fmap', because it
> introduces two different names for the same thing (and I find the name
> `fmap' awkward).
I strongly concur. There are far too many maps even without
that, and having two
Hello,
I never liked the decision to rename 'map' to 'fmap', because it
introduces two different names for the same thing (and I find the name
`fmap' awkward).
As far as I understand, this was done to make it easier to learn
Haskell, by turning errors like "Cannot discharge constraint 'Functor
X'
Hello,
I know we have discussed this before, I am just posting this so that
it does not appear that the "community" does not care. Here is a
summary of why I think Functor should be a super class of Monad. The
extra code that a programmer would have to write is very small:
instance Functor MyM
On Mon, Aug 14, 2006 at 12:02:58AM -0500, Taral wrote:
> In my opinion, an instance definition of a subclass should allow the
> superclass's methods to be defined as if they were part of the
> subclass, e.g.:
>
> instance Monad [] where
>fmap = map
>return x = [x]
>join = concat
>
> I
Hello Taral,
Monday, August 14, 2006, 3:34:29 PM, you wrote:
> On 8/14/06, Jon Fairbairn <[EMAIL PROTECTED]> wrote:
>> of course, there's no reason to do that, but what I'm
>> proposing is that we allow default instance declarations in
>> class declarations in much the same way as default methods
On 8/14/06, Jon Fairbairn <[EMAIL PROTECTED]> wrote:
of course, there's no reason to do that, but what I'm
proposing is that we allow default instance declarations in
class declarations in much the same way as default methods:
I just realized that default superclass methods have a small problem
Hello Jon,
Monday, August 14, 2006, 1:49:58 PM, you wrote:
>> > instance Monad [] where
>> > fmap = map
>> > return x = [x]
>> > join = concat
>>
>> i support this idea. [...]
> I'm not sure it's quite right. Surely it only makes sense if
> it defines all the (necessary) superclass
On 2006-08-14 at 12:03+0400 Bulat Ziganshin wrote:
> Hello Taral,
>
> Monday, August 14, 2006, 9:02:58 AM, you wrote:
>
> > In my opinion, an instance definition of a subclass should allow the
> > superclass's methods to be defined as if they were part of the
> > subclass, e.g.:
>
> > instance M
Hello Taral,
Monday, August 14, 2006, 9:02:58 AM, you wrote:
> In my opinion, an instance definition of a subclass should allow the
> superclass's methods to be defined as if they were part of the
> subclass, e.g.:
> instance Monad [] where
> fmap = map
> return x = [x]
> join = conc
15 matches
Mail list logo
