Hi,
Chp 8 of the Haskell Report says:
In this chapter the entire Haskell Prelude is given. It constitutes a
*specification* for the Prelude.
Many of the definitions are written with clarity rather than
efficiency in mind, and it is not required
that the specification be implemented as shown h
* * * Johannes Waldmann wrote:
> > But if you want to be really weird you can write something
> > like (I haven't typed this in):
> >
> > f x | (Foo _) == x =
> > f x | (Bar _) == x =
>
> no, you can't, e. g. hugs (Feb 2000) says
>
> Prelude> let f x | Just 4 == x = 0 in f (Just 4)
> 0
> Prel
* * * Ketil Malde <[EMAIL PROTECTED]> wrote:
> ut - the converse is not true, is it? I can write
>
> ... = case foo of
>(Foo f) -> ...
>(Bar b) -> ...
>
> ut I can't express that as a pattern-guarded expression, can I?
You probably have already seen John's
* * * Ketil Malde <[EMAIL PROTECTED]> wrote:
> > runRandom last max num
> > | num > 1 = runRandom (fst new) max (num-1)
> > | otherwise = snd new
>
> What's the difference between the pipe-syntax, and a case statement,
> i.e. writing the function as
>
> runRandom last max num = case n
> > I don't have a clear picture about common practice regarding argument
> > order. Any ideas for simple rules which cover most cases?
>
> For functions that take an old version of something plus some modifiers
> and return a new version, current practice is inconsistent.
Fusion rules (cata-bui
Paul Hudak wrote:
> P.S. I really like the idea someone suggested of maintaining a list of
> open projects, who's working on what, etc. as in the Linux community.
One major difference between the Linux community and the Haskell
community is that in LinuxLand the reward is the name, recognition,
Mark Jones wrote:
> One of the greatest disappointments to date of the move
> to more liberal (i.e. free software) licenses for systems
> like Hugs and GHC, is that it has done almost nothing to
> stimulate contributions to the implementations themselves
> from outside the immediate (and small) g
Erik Meijer wrote:
> Zipping lists however is *much* easier expressed using anamorphisms
> or unfold. The reason is that when zipping two lists you are
> co-inductively *constructing* a list, and not so much inductively
> destructing a list. Hence the trick of inductively destructing a
> list tha
Lennart Augustsson wrote:
>
> Kevin Atkinson wrote:
>
> > Lennart Augustsson wrote:
> >
> > > No, it will not be as efficient. foldr is not the right primitive for making
> > > functions on lists. You want the more general
> > > recurse :: (a -> c a -> b -> b) -> b -> c a -> b
> >
> > Could
Kevin Atkinson wrote:
> cons :: a -> c a -> c a
> empty :: c
> foldr :: (a -> b -> b) -> b -> c a -> b
I am not an expert. I have a minor problem with this, the type of
empty: if c stands for a type constructor then empty should have type
(c a). Moreover, I don't understand why you use 'c'
efinitions for + and ^. So I wanted to fetch them from the
archive...which was last updated on the 28 May. Is the archive broken
or just rarely updated?
Thanks,
Laszlo Nemeth
, but I'm in the habit of publishing
>proposals before implementing them.
Will this change be compatible with the first class (extensible?)
records work?
I know that first class records will not be part of Haskell98, but
it would be nice if Haskell2000 (or whatever) could be close to the
stable language of H98.
Can we expect first class records in the near future?
Laszlo Nemeth
Chris Okasaki wrote:
> Unfortunately, it's not quite that easy. For a library with several
> implementations
> of, say, sets, you want the various implementations to support the same
> fold function. In other words, in a library with abstract data types, you
> want
> the folds to be over the ab
ons which I generate
later, I'd be happy to give you a copy. (It's 3.02, I'm afraid)
Laszlo Nemeth
[EMAIL PROTECTED]
14 matches
Mail list logo
