>> One of the goals of Standard Haskell was to simplify the language
>> - removing traps and making it easier to teach/learn.
Speaking of this, when is someone going to write an fp book that teaches
all the interesting stuff? Monads, advanced use of classes, advanced types
in general, exceptions
> > > class Aggregate a where
> > > toList::(Num b)=>a->[b]
> > > fromList::(Num b)=>[b]->a
> >
> > > data MyAgg =Agg Int Int
> > > instance Aggregate MyAgg where
> > > toList (Agg x y) = [x,y]
> > > fromList [x,y] = (Agg x y)
> I understand what it is saying. I don't understand why it is
This is a reply to Fergus Henderson's comments on my proposal.
My answer to all his comments is that consistent languages are
easier to learn than languages littered with exceptions, special cases
and random default behaviour.
> > 1) Fixity declarations usually look like this:
> > infixl
> what laws should hold for the (++) operation?
Associativity and leftward distributivity are missing in the Report:
(m ++ n) ++ o = m ++ (n ++ o)
(m ++ n) >>= k = (m >>= k) | (n >>= k)
On the other hand right distributivity does not hold in general.
Conversely, the report
On Sat, 20 Jun 1998, Lennart Augustsson wrote:
> > > class Aggregate a where
> > > toList::(Num b)=>a->[b]
> > > fromList::(Num b)=>[b]->a
> >
> > > data MyAgg =Agg Int Int
> > > instance Aggregate MyAgg where
> > > toList (Agg x y) = [x,y]
> > > fromList [x,y] = (Agg x y)
> The type of toLi
On Fri, 19 Jun 1998 [EMAIL PROTECTED] wrote:
> Ok, let's go to "stateless" SQL statements.
> Where would you like to connect to database?
I think part of the confusion here is that I am thinking in terms of
databases with explicit support for transactions rather than Xbase and
Access databases wh
what laws should hold for the (++) operation?
the haskell report says:
zero ++ m = m = m ++ zero
i'd additionally expected something like
join x ++ join y = join (x ++ y)
but this might be too restrictive,
since it forces the monad to be a list monad?
for instance (sic), it fa