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. Understanding Haskell Map.lookup Example in LYH (Olumide)
2. Re: Understanding Haskell Map.lookup Example in LYH
(Francesco Ariis)
3. Re: Doubts about functional programming paradigm (John Lusk)
4. Re: Doubts about functional programming paradigm
(Imants Cekusins)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Dec 2015 12:36:49 +0000
From: Olumide <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] Understanding Haskell Map.lookup Example
in LYH
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello Haskellers!
I'd appreciate help understanding the origin of the extra 'map' in
'Map.lookup lockerNumber map', from the following example taken from
chapter 8 of "Learn You a Haskell for Great Good"
http://learnyouahaskell.com/making-our-own-types-and-typeclasses#type-synonyms
lockerLookup :: Int -> LockerMap -> Either String Code
lockerLookup lockerNumber map =
case Map.lookup lockerNumber map of
Nothing -> Left $ "Locker number " ++ show lockerNumber ++ "
doesn't exist!"
Just (state, code) -> if state /= Taken
then Right code
else Left $ "Locker " ++ show
lockerNumber ++ " is already taken!"
Regards,
- Olumide
------------------------------
Message: 2
Date: Mon, 14 Dec 2015 13:42:34 +0100
From: Francesco Ariis <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Understanding Haskell Map.lookup
Example in LYH
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Mon, Dec 14, 2015 at 12:36:49PM +0000, Olumide wrote:
> Hello Haskellers!
>
> I'd appreciate help understanding the origin of the extra 'map' in
> 'Map.lookup lockerNumber map', from the following example taken from chapter
> 8 of "Learn You a Haskell for Great Good"
> http://learnyouahaskell.com/making-our-own-types-and-typeclasses#type-synonyms
>
> lockerLookup :: Int -> LockerMap -> Either String Code
> lockerLookup lockerNumber map =
> case Map.lookup lockerNumber map of
> Nothing -> [...]
Hello Olumide,
`map` is just a parameter name. `Map.lookup` type is
?> :t Data.Map.lookup
Data.Map.lookup :: Ord k => k -> Map k a -> Maybe a
(so a key and a container, returning `Maybe a`). The name `map` for the
second parameter is unfortunate because it is the same as the much
loved `map` function; in this case map-the-function get shadowed by
the-parameter-named-map.
I hope this helps, if not fire again!
------------------------------
Message: 3
Date: Mon, 14 Dec 2015 12:19:46 -0500
From: John Lusk <[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:
<CAJQkMba5JDm2CfEhOTfUBTUbXz1kp=8qWsb7mUkkhe=un0g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dude... it's the Haskell *Beginners* List.
STM, I guess, is Shared Transactional Memory.
But OTP? Wazzat?
On Fri, Dec 11, 2015 at 4:36 PM, Christopher Allen <[email protected]>
wrote:
> Having the option of communicating by sharing memory, message-passing
> style (copying), or copy-on-write semantics in Haskell programs is why I've
> found Haskell to be a real pleasure for performance (latency, mostly)
> sensitive services I frequently work on. I get a superset of options in
> Haskell for which I don't have any one choice that can really match it in
> concurrency problems or single-machine parallelism. There's some work to be
> done to catch up to OTP, but the community is inching its way a few
> directions (Cloud Haskell/distributed haskell, courier, streaming lib +
> networking, etc.)
>
> Generally I prefer to build out services in a conventional style (breaking
> out capacities like message backends or persistence into separate
> machines), but the workers/app servers are all in Haskell. That is, I don't
> try to replicate the style of cluster you'd see with Erlang services in
> Haskell, but I know people that have done so and were happy with the
> result. Being able to have composable concurrency via STM without
> compromising correctness is _no small thing_ and the cheap threads along
> with other features of Haskell have served to make it so that concurrency
> and parallelization of Haskell programs can be a much more modular process
> than I've experienced in many other programming languages. It makes it so
> that I can write programs totally oblivious to concurrency or parallelism
> and then layer different strategies of parallelization or synchronization
> after the fact, changing them out at runtime if I so desire! This is only
> possible for me in Haskell because of the non-strict semantics and
> incredible kit we have at our disposal thanks to the efforts of Simon
> Marlow and others. Much of this is ably covered in Marlow's book at:
> http://chimera.labs.oreilly.com/books/1230000000929
>
> Side bar: although using "pure" with respect to effects is the common
> usage now, I'd urge you to consider finding a different wording since the
> original (and IMHO more meaningful) denotation of pure functional
> programming was about semantics and not the presence or absence of effects.
> The meaning was that you had a programming language whose semantics were
> lambda-calculus-and-nothing-more. This can be contrasted with ML where the
> lambda calculus is augmented with an imperative language that isn't
> functional or a lambda calculus. Part of the problem with making purity
> about effects rather than semantics is the terrible imprecision confuses
> new people. They'll often misunderstand it as, "Haskell programs can't
> perform effects" or they'll think it means stuff in "IO" isn't pure - which
> is false. We benefit from having a pure functionalal programming language
> _especially_ in programs that emit effects. Gabriel Gonzalez has a nice
> article demonstrating some of this:
> http://www.haskellforall.com/2015/03/algebraic-side-effects.html
>
> When I want to talk about effects, I say "effect". When I want to say
> something that doesn't emit effects, I say "effect-free" and when it does,
> "effectful". Sometimes I'll say "in IO" for the latter as well, where "in
> IO" can be any type that has IO in the outermost position of the final
> return type.
>
> But, in the end, I'm not really here to convince anybody to use Haskell.
> I'm working on http://haskellbook.com/ with my coauthor Julie because I
> thought it was unreasonably difficult and time-consuming to learn a
> language that is quite pleasant and productive to use in my day to day
> work. If Haskell picks up in popularity, cool - more libraries! If not,
> then it remains an uncommon and not well-understood competitive advantage
> in my work. I'm not sure I mind either outcome as long as the community
> doesn't contract and it seems to be doing the opposite of that lately.
>
> I use Haskell because I'm lazy and impatient. I do not tolerate tedious,
> preventable work well. Haskell lets me break down my problems into
> digestible units, it forces the APIs I consume to declare what chicanery
> they're up to, it gives me the nicest kit for my work I've ever had at my
> disposal. It's not perfect - it's best if you're comfortable with a unix-y
> toolkit, but there's Haskellers on Windows keeping the lights on too.
>
> Best of luck to Abhishek whatever they decide to do from here. I won't
> pretend Haskell is "easy" - you have to learn more before you can write the
> typical software project, but it's an upfront cliff sorta thing that
> converts into a long-term advantage if you're willing to do the work. This
> is more the case than what I found with Clojure, Erlang, Java, C++, Go,
> etc. They all have a gentler upfront productivity cliff, but don't pay off
> nearly as well long-term in my experience. YMMV.
>
> On Fri, Dec 11, 2015 at 3:13 PM, Darren Grant <[email protected]> wrote:
>
>> Regarding concurrency+immutability with respect to both reliability and
>> performance:
>>
>> One way to think about synchronizing concurrent programs is by sharing
>> memory. If the content of that memory changes, then there is a risk of race
>> conditions arising in the affected programs. (A common source of vexing
>> bugs, and complications for compilers.) But if the contents are somehow
>> guaranteed not to change (ie. a specific definition of immutability), then
>> no race conditions are possible for the lifetime of access to that memory.
>>
>> Although this is a greatly simplified illustrative explanation, it is
>> generally at the heart of arguments for immutability aiding performance.
>> Unchanging regions of memory tend to permit simpler sorts of models since
>> limitations are lifted on synchronization. This in turn allows both more
>> freedom to pursue many otherwise tricky optimizations, such as ex. deciding
>> when to duplicate based on cache geometry, trivially remembering old
>> results, etc.
>>
>> Regarding the discourse on purely functional programs not having side
>> effects:
>>
>> Writing pure programs without side effects is a little tricky to talk
>> about, since this has some very precise technical meanings depending on
>> whom you talk to. (What constitutes an effect? Where is the line between
>> intentional and unintentional drawn?)
>>
>> Maybe think of this statement as part of the continuum of arguments about
>> languages that allow us to write simpler programs that more precisely state
>> the intended effects.
>>
>> Cheers,
>> Darren
>> On Dec 11, 2015 07: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.
>>> Thanks
>>> Abhishek Kumar
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
> _______________________________________________
> 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/20151214/565bc6d4/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 14 Dec 2015 18:24:59 +0100
From: Imants Cekusins <[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:
<CAP1qinbmvd=W1B5poWf=pmyh-1whq_4u7n-eft1spfstwf9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Erlang OTP
http://www.erlang.org/
https://en.m.wikipedia.org/wiki/Open_Telecom_Platform
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151214/a3a7e76a/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 90, Issue 27
*****************************************
