The main thing holding up porting of content from the old wiki is
licensing. In order to help this, could people who've written for the
old wiki, and are happy to have that work moved to the new wiki and
relicensed, add their names to the list here:
Matthias Fischmann wrote:
Do you expect the contained type x to change during a
sequence of monadic actions? e.g. would you ever use
(=)
at the type 'Permutation Int - (Int - Permutation
Bool) -
Permutation Bool'?
no, i don't need that. but aside from
the fact that
data
Hello Luis,
Friday, October 6, 2006, 6:52:04 AM, you wrote:
I have recently started editing a page on the Haskell.org wiki site
dedicated to our spanish-speaker community.[0]
i had the same idea about Russian page although still not implemented it
I also expect we could get some of the main
On Sun, Oct 08, 2006 at 10:57:46PM +1300, [EMAIL PROTECTED] wrote:
To: haskell-cafe@haskell.org
From: [EMAIL PROTECTED]
Date: Sun, 08 Oct 2006 22:57:46 +1300
Subject: [Haskell-cafe] collection monads
Matthias Fischmann wrote:
Do you expect the contained type x to change during a
This email actually turned out much longer than I expected, but I hope
it sparks interesting (and hopefully, thorough!) discussion on points
that weren't touched on by previous threads on this topic. What
follows describes my journey thus far exploring what I see (as a
newcomer to Haskell) as a
... and here is the code I am giving up on for today: Serialization of
HLists. Questions below.
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
{-# OPTIONS -fallow-overlapping-instances #-}
module Foo where
import Char
import List
import Monad
import Permutation
Hello,
admittedly, there is a lack of material on lazy evaluation and
performance. IMHO, the current wiki(book) and other articles are
somewhat inadequate which stems from the fact that current rumor is
strictness is fast and arrays must be unboxed or so. I don't agree
with this, so I post some
On 10/8/06, Yang [EMAIL PROTECTED] wrote:
And do most (experienced) Haskell
users sacrifice cleanliness for speed, or speed for cleanliness?
Keep the internals of your code--that which will be looked at a
lot--fast and ugly, while the rest can be clean. If you have a
function that does
On 10/8/06, ihope [EMAIL PROTECTED] wrote:
Keep the internals of your code--that which will be looked at a
lot--fast and ugly, while the rest can be clean.
Sorry. Meant that which will be used a lot.
___
Haskell-Cafe mailing list
On 10/8/06, ihope [EMAIL PROTECTED] wrote:
On 10/8/06, Yang [EMAIL PROTECTED] wrote:
And do most (experienced) Haskell
users sacrifice cleanliness for speed, or speed for cleanliness?
Keep the internals of your code--that which will be looked at a
lot--fast and ugly, while the rest can be
On Sun, 2006-10-08 at 15:25 -0700, Jason Dagit wrote:
Another good idea when you have a pretty version which is easy to
verify for correctness and an ugly version that is harder to verify is
to use QuickCheck or SmallCheck and define a property that says both
versions are equal for all
duncan.coutts:
On Sun, 2006-10-08 at 15:25 -0700, Jason Dagit wrote:
Another good idea when you have a pretty version which is easy to
verify for correctness and an ugly version that is harder to verify is
to use QuickCheck or SmallCheck and define a property that says both
versions are
Yang wrote:
type Poly = [(Int,Int)]
addPoly1 :: Poly - Poly - Poly
addPoly1 p1@(p1h@(p1c,p1d):p1t) p2@(p2h@(p2c,p2d):p2t)
| p1d == p2d = (p1c + p2c, p1d) : addPoly1 p1t p2t
| p1d p2d = p1h : addPoly1 p1t p2
| p1d p2d = p2h : addPoly1 p1 p2t
addPoly1 p1 [] = p1
addPoly1 [] p2 =
13 matches
Mail list logo
