Send Beginners mailing list submissions to
beginners@haskell.org
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
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: IO a, IO b (Imants Cekusins)
2. Re: Doubts about functional programming paradigm (Jeffrey Brown)
3. Re: Doubts about functional programming paradigm (Rein Henrichs)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Dec 2015 18:04:27 +0100
From: Imants Cekusins <ima...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] IO a, IO b
Message-ID:
<cap1qinyvcacslmpqvomvvv9jmsa_6us0qoxzpjhrt4wm2ya...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
my apologies.
IO b was declared a newtype. After changing it to type, container
function seems to work as it is.
Please ignore.
------------------------------
Message: 2
Date: Tue, 15 Dec 2015 11:24:56 -0800
From: Jeffrey Brown <jeffbrown....@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID:
<CAEc4Ma0D0DeBJvg_VVmBjXqUof6E+BDz=wtZ_hh2H7Q-=t3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Purity makes type signatures astonishingly informative. Often -- in fact
usually! -- one can determine what a function does simply from its name and
type signature.
The opportunities for bad coding are fewer in Haskell. Before Haskell, I
was a proud Python programmer -- proud, thinking I was good at selecting
the right way from a forest of wrong ways. In Haskell I find less
opportunity for self-congratulation, because most of the wrong ways are no
longer available.
On Tue, Dec 15, 2015 at 9:00 AM, derek riemer <driemer.rie...@gmail.com>
wrote:
> Hey guys,
> This conversation is really interesting. I am not a haskell expert (I
> haven't progressed into monads in haskell yet, and have only briefly
> studied the state monad in scala. Studying fp concepts has changed the way
> I think about problems that are complicated. I am not quite there yet, (I
> still catch myself updating states when I don't need to) and wondering how
> the hell to break a problem into recursive little bits. I now notice that I
> am less tempted to do things that would have bugs in complicated data
> structures , prefer map to do something to a list, and folds to for loops
> that update a ``state'' variable, and finally, I can reason about where the
> weak points in my code may be. The learning I have achieved do to fp, and
> my principals of programming languages class that relied on fp, have made
> doing things with code easier because I don't try to do stupid things like
> overrun the end of an array with a misplaced loop counter variable. It is
> way too easy to learn fold, filter, map, and list comprehensions, you then
> have a powerful weapon to use against those ugly off by one errors.
> Also, I learned how people who learned programming in non-traditional
> languages might think to approach problems earlier this year. My stats
> professor was showing us things in r. She showed us a complicated set of
> formula that we needed to do, and then explained we were calculating
> something to each element of a list. She showed a function sapply(vector,
> function(elem)) that returns a vector. She said to think about how sapply
> applies that function to each vector element, and returns the transformed
> list. She didn't approach it as if it were this big bad function that takes
> a function, mainly i think because she hadn't learned programming from
> people who insist on the idea of c. It also really made sense to the class
> who mainly had little to no programming experience, where explaining a for
> loop in all it's glory would normally take a couple of lectures. She is a
> really solid programmer and really understands how to use programming to
> solve real world problems, so I am not saying that she didn't know enough
> to have not learned for loops, just that she immediately realized that the
> sapply function really was better for the situation. If we teach people
> these patterns from the get go, I think some of the horror of learning
> functional programming would be solved because the number of applications
> that a generic function can be applied in far outnumbers the number of
> cases a for loop or state momad is needed. I would also now argue that all
> data structures classes should be taught in functional programming
> languages. I never solidly understood trees and could confidently traverse
> and change them until I actually got introduced to pattern matching and
> folds. I was taught binary search trees, and red-black trees, and worked
> with tree like structures, but it was always hard for me to comprehend how
> to do things with them. I learned linked lists in c++ but hated them with a
> passion because I had to write forloops that updated a temporary variable
> and write while loops that did the same, but often jumped off the end of
> the list and then I couldn't go back. The beauty of recursion and lists is
> that recursion allows you to backtrack when things go wrong (as they always
> will for any real input in a program). The second I learned about Haskell
> for the first time, linked list traversing became second nature to me, even
> in non-functional (inferier) c++. The argument that "recursion results in
> overriding the stack" is kind of a flawed one since the compiler wizards
> have figured out ways to optimize tail recursive functions to do exactly
> what we humans are bad at (running recursive functions as if they were
> unrolled, with large inputs, and fast).
> Thanks,
> Derek
>
>
> On 12/11/2015 11:32 AM, Thomas Jakway wrote:
>
> 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 <matthewjwilliams...@gmail.com>
> <matthewjwilliams...@gmail.com> 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 <ber...@alum.mit.edu> <ber...@alum.mit.edu>
> wrote:
>
> On 2015-12-11 at 10:07, Abhishek Kumar <abhishekkm...@gmail.com>
> <abhishekkm...@gmail.com> 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 Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing
> listBeginners@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
> --
> ------------------------------
> Derek Riemer
>
> - Department of computer science, third year undergraduate student.
> - Proud user of the NVDA screen reader.
> - Open source enthusiast.
> - Member of Bridge Cu
> - Avid skiier.
>
> Websites:
> Honors portfolio <http://derekriemer.drupalgardens.com>
> Non-proffessional website.
> <http://derekriemer.pythonanywhere.com/personal>
> Awesome little hand built weather app that rocks!
> <http://derekriemer.pythonanywhere.com/weather>
>
> email me at derek.rie...@colorado.edu <derek.rie...@colorado.edu>
> Phone: (303) 906-2194
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
--
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151215/8dcee123/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 15 Dec 2015 12:13:20 -0800
From: Rein Henrichs <rein.henri...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Doubts about functional programming
paradigm
Message-ID:
<m21tan79nj.fsf@Reins-iMac.local.i-did-not-set--mail-host-address--so-tickle-me>
Content-Type: text/plain
Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It
sounds like an amazing experience.
> There is no authoritative source about these pragmas. They are listed
> and described in the GHC User Guide, but that source all too often
> defines solely by example, not even bolstered by a formal syntax
> specification.
I think it would very helpful simply to better (and more rigorously)
document the syntax and semantics of the available extensions. There is
currently a call to action to update GHC's Haddock documentation in
preparation for the 8.0 release [1]. Perhaps some effort can also be
directed towards the documentation of the LANGUAGE pragmas.
There is still a problem, though: For completeness, one must consider
the interactions of the various subsets of these pragmas, some of which
are already known to be unsound. What's worse, the number of extant
pragmas already makes an enumeration of these subsets impractical, since
there are some 10^31 of them even ignoring the "NoX" pragmas.
The only long-term solution then seems to be to codify a new Haskell
standard that incorporates some known-good subset of these pragmas that
the community seems to agree on, which I suppose is part of the task
that the Haskell Prime committee has before them. I do not envy them.
[1]: https://mail.haskell.org/pipermail/ghc-devs/2015-December/010681.html
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 90, Issue 32
*****************************************
