Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Help with expressing polymorphic return type (Marco Yuen)
2. Re: Haskell code optimisation (Kim-Ee Yeoh)
3. Re: Doubts about functional programming paradigm (Daniel Bergey)
4. Re: Doubts about functional programming paradigm (MJ Williams)
5. Re: Doubts about functional programming paradigm (Thomas Jakway)
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Dec 2015 10:38:14 -0500
From: Marco Yuen <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] Help with expressing polymorphic return
type
Message-ID:
<CADrGu4m-eo5eyXk7wr+9DeUq-=q9jwatunusose33tdz-ap...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
{-# LANGUAGE TypeFamilies #-}
data CB = CB deriving (Show)
data CO = CO deriving (Show)
data CBParseResult = CBParseResult deriving (Show)
data COParseResult = COParseResult deriving (Show)
class ParseResult a where
type EntityType a :: *
toEntity :: a -> EntityType a
instance ParseResult CBParseResult where
type EntityType CBParseResult = CB
toEntity result = CB
instance ParseResult COParseResult where
type EntityType COParseResult = CO
toEntity result = CO
getParseResult :: (ParseResult r) => String -> IO r
getParseResult i = do
if someCond
then return CBParseResult
else return COParseResult
where
someCond = null i
Couldn't match expected type ?r? with actual type ?COParseResult?
?r? is a rigid type variable bound by
the type signature for
getParseResult :: ParseResult r => String -> IO r
at Parse.hs:19:19
Relevant bindings include
getParseResult :: String -> IO r (bound at Parse.hs:20:1)
In the first argument of ?return?, namely ?COParseResult?
In the expression: return COParseResult
What I want to express is getParseResult to be able to return any instances
of ParseResult type class. But what I understand from the error is that r
has been specialized to CBParseResult, but in the next expression I'm
returning COParseResult. Is my understanding correct? And, How would I
express what I described?
Thanks,
Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151211/1cade41d/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 11 Dec 2015 22:44:41 +0700
From: Kim-Ee Yeoh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Haskell code optimisation
Message-ID:
<capy+zdq5yhazihsn7+cu01e3tnocfar32xcatr--mjc1yja...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Have you tried BangPatterns? Compiled with optimization, I get 22 secs.
Here's the full program:
{-# LANGUAGE BangPatterns #-}
f :: Int -> Int -> Int
f !m !n
| m==0 = n+1
| n==0 = f (m-1) 1
| otherwise = f (m-1) (f m (n-1))
main = putStrLn (show (f 4 1))
-- Kim-Ee
On Fri, Dec 11, 2015 at 9:47 PM, Abhishek Kumar <[email protected]>
wrote:
> I was trying to write below program for ackerman function but it fails
> (waits too long) for ack(4,1) whereas a recursive C program gives result in
> 37secs.Can someone pls explain this behaviour and recomend some
> optimisation.
>
> ------haskell code
> f m n | m==0 =n+1
> | n==0 = f (m-1) 1
> | otherwise = f (m-1) (f m (n-1))
>
> Thanks
> Abhishek Kumar
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151211/d198138a/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 11 Dec 2015 11:22:24 -0500
From: Daniel Bergey <[email protected]>
To: Abhishek Kumar <[email protected]>, The Haskell-Beginners
Mailing List - Discussion of primarily beginner-level topics related
to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID:
<874mfp9cqn.fsf@chladni.i-did-not-set--mail-host-address--so-tickle-me>
Content-Type: text/plain
On 2015-12-11 at 10:07, Abhishek Kumar <[email protected]> wrote:
> I am a beginner in haskell.I have heard a lot about haskell being great for
> parallel programming and concurrency but couldn't understand why?Aren't
> iterative algorithms like MapReduce more suitable to run parallely?Also how
> immutable data structures add to speed?I'm having trouble understanding
> very philosophy of functional programming, how do we gain by writing
> everything as functions and pure code(without side effects)?
> Any links or references will be a great help.
Functional languages make it easy to decompose problems in the way that
MapReduce frameworks require. A few examples (fold is another name for
reduce):
sum :: [Double] -> Double
sum xs = foldr (+) 0 xs
sumSquares :: [Double] -> Double
sumSquares xs = foldr (+) 0 (map (**2) xs)
-- foldMap combines the map & fold steps
-- The Monoid instance for String specifies how to combine 2 Strings
-- Unlike numbers, there's only one consistent option
unlines :: [Text] -> Text
unlines xs = foldMap (`snoc` '\n') xs
We'd need a few changes[1] to make this parallel and distribute across many
computers, but expressing the part that changes for each new MapReduce
task should stay easy.
Immutable data by default helps with concurrency. Speed may or may not be
the goal. We want to be able to distribute tasks (eg, function calls)
across processor cores, and run them in different order, without
introducing race conditions.
Simon Marlow's book is great at explaining parallel & concurrent
concepts, and the particular tools for applying them in Haskell:
http://chimera.labs.oreilly.com/books/1230000000929
bergey
Footnotes:
[1] OK, many changes.
------------------------------
Message: 4
Date: Fri, 11 Dec 2015 18:08:11 +0000
From: MJ Williams <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID:
<caakj9fptlq9+4fgt96u3y0rrq62bprkvktt+j1h2j4bk_cf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
A pure functional language enables you to reason about your code,
something you can't easily achieve with your average C or Java. And by
`reason' I am referring to mathematical proof. Haskell makes it very
simple, actually. Why should you want to reason about your code?
Think the hassle you could avoid if you knew what your code really
meant and did when executed.
The absence of side effects is part of another concept in FP, namely,
`referential transparency'. If your function `f' maps a value `x' to
a value `y' then `f x' will always equal `y' and no more. In other
words, your function `f' won't change anything e.g. assign to
variables, or other state changes as well as mapping `x' to `y', and
that's an absolute certainty, in theory, at any rate.
That's a very crude overview of at least part of what functional
programming is about. I'm hoping it'll encourage others on this list
with far more in-depth knowledge of the subject matter to come in and
fill in the gaps and iron out the ambiguities.
Matthew
On 11/12/2015, Daniel Bergey <[email protected]> wrote:
> On 2015-12-11 at 10:07, Abhishek Kumar <[email protected]> wrote:
>> I am a beginner in haskell.I have heard a lot about haskell being great
>> for
>> parallel programming and concurrency but couldn't understand why?Aren't
>> iterative algorithms like MapReduce more suitable to run parallely?Also
>> how
>> immutable data structures add to speed?I'm having trouble understanding
>> very philosophy of functional programming, how do we gain by writing
>> everything as functions and pure code(without side effects)?
>> Any links or references will be a great help.
>
> Functional languages make it easy to decompose problems in the way that
> MapReduce frameworks require. A few examples (fold is another name for
> reduce):
>
> sum :: [Double] -> Double
> sum xs = foldr (+) 0 xs
>
> sumSquares :: [Double] -> Double
> sumSquares xs = foldr (+) 0 (map (**2) xs)
>
> -- foldMap combines the map & fold steps
> -- The Monoid instance for String specifies how to combine 2 Strings
> -- Unlike numbers, there's only one consistent option
> unlines :: [Text] -> Text
> unlines xs = foldMap (`snoc` '\n') xs
>
> We'd need a few changes[1] to make this parallel and distribute across many
> computers, but expressing the part that changes for each new MapReduce
> task should stay easy.
>
> Immutable data by default helps with concurrency. Speed may or may not be
> the goal. We want to be able to distribute tasks (eg, function calls)
> across processor cores, and run them in different order, without
> introducing race conditions.
>
> Simon Marlow's book is great at explaining parallel & concurrent
> concepts, and the particular tools for applying them in Haskell:
> http://chimera.labs.oreilly.com/books/1230000000929
>
> bergey
>
> Footnotes:
> [1] OK, many changes.
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
------------------------------
Message: 5
Date: Fri, 11 Dec 2015 13:32:55 -0500
From: Thomas Jakway <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Building on that, I think coming to Haskell with a very specific goal in mind
(like swap Haskell for Java in my map reduce problem) kind of misses the
point.? Haskell may or may not be faster/better suited to map reduce vs Java,
but the real reason to use/learn Haskell is elegance and correctness.? The lack
of side effects and referential transparency means you're far more likely to
prevent bugs. And there's a pretty substantial learning curve coming from
imperative languages so if you need to speed up map reduce on a deadline you
will be more productive in the imperative language of your choice (for now).
Dont take this as discouragement, I think Haskell (and FP in general) is very
well suited to that kind of problem. I'm a beginner in Haskell and it's
already had a huge impact on how I think about all the code I write, not just
the occasional toy Haskell project.
On Dec 11, 2015 1:08 PM, MJ Williams <[email protected]> wrote:
>
> A pure functional language enables you to reason about your code,
> something you can't easily achieve with your average C or Java. And by
> `reason' I am referring to mathematical proof. Haskell makes it very
> simple, actually.? Why should you want to reason about your code?
> Think the hassle you could avoid if you knew what your code really
> meant and did when executed.
>
> The absence of side effects is part of another concept in FP, namely,
> `referential transparency'.? If your function `f' maps a value `x' to
> a value `y' then `f x' will always equal `y' and no more. In other
> words, your function `f' won't change anything e.g. assign to
> variables, or other state changes as well as mapping `x' to `y', and
> that's an absolute certainty, in theory, at any rate.
>
> That's a very crude overview of at least part of what functional
> programming is about.? I'm hoping it'll encourage others on this list
> with far more in-depth knowledge of the subject matter to come in and
> fill in the gaps and iron out the ambiguities.
>
> Matthew
>
>
> On 11/12/2015, Daniel Bergey <[email protected]> wrote:
> > On 2015-12-11 at 10:07, Abhishek Kumar <[email protected]> wrote:
> >> I am a beginner in haskell.I have heard a lot about haskell being great
> >> for
> >> parallel programming and concurrency but couldn't understand why?Aren't
> >> iterative algorithms like MapReduce more suitable to run parallely?Also
> >> how
> >> immutable data structures add to speed?I'm having trouble understanding
> >> very philosophy of functional programming, how do we gain by writing
> >> everything as functions and pure code(without side effects)?
> >> Any links or references will be a great help.
> >
> > Functional languages make it easy to decompose problems in the way that
> > MapReduce frameworks require.? A few examples (fold is another name for
> > reduce):
> >
> > sum :: [Double] -> Double
> > sum xs = foldr (+) 0 xs
> >
> > sumSquares :: [Double] -> Double
> > sumSquares xs = foldr (+) 0 (map (**2) xs)
> >
> > -- foldMap combines the map & fold steps
> > -- The Monoid instance for String specifies how to combine 2 Strings
> > -- Unlike numbers, there's only one consistent option
> > unlines :: [Text] -> Text
> > unlines xs = foldMap (`snoc` '\n') xs
> >
> > We'd need a few changes[1] to make this parallel and distribute across many
> > computers, but expressing the part that changes for each new MapReduce
> > task should stay easy.
> >
> > Immutable data by default helps with concurrency.? Speed may or may not be
> > the goal.? We want to be able to distribute tasks (eg, function calls)
> > across processor cores, and run them in different order, without
> > introducing race conditions.
> >
> > Simon Marlow's book is great at explaining parallel & concurrent
> > concepts, and the particular tools for applying them in Haskell:
> > http://chimera.labs.oreilly.com/books/1230000000929
> >
> > bergey
> >
> > Footnotes:
> > [1]? OK, many changes.
> >
> > _______________________________________________
> > Beginners mailing list
> > [email protected]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 90, Issue 19
*****************************************
