Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/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. Re: f . g or f g or f $ g? (mukesh tiwari)
2. Re: Parsec simple question (Brandon Allbery)
3. Re: f . g or f g or f $ g? (Paul Higham)
4. Re: Beginners Digest, Vol 56, Issue 20 (Michael Orlitzky)
5. Re: f . g or f g or f $ g? (Ertugrul S?ylemez)
6. Re: f . g or f g or f $ g? (Mateusz Kowalczyk)
----------------------------------------------------------------------
Message: 1
Date: Wed, 13 Feb 2013 03:14:32 +0530
From: mukesh tiwari <[email protected]>
Subject: Re: [Haskell-beginners] f . g or f g or f $ g?
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<CAFHZvE92uBT8OTnge4ZvB_ybRy-48dnujWM9UXSv=xqbfmm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
You can write (f . g) x as f . g $ x so for me, it's avoiding extra
parenthesis.
Mukesh
On Wed, Feb 13, 2013 at 2:53 AM, Emanuel Koczwara <[email protected]
> wrote:
> Hi,
>
> Dnia 2013-02-12, wto o godzinie 22:09 +0100, Martin Drautzburg pisze:
> > On Friday, 1. February 2013 23:02:39 Ertugrul S?ylemez wrote:
> >
> > > (f . g) x = f (g x)
> >
> >
> > so (f . g) x = f $ g x
> >
> > right?
> >
> > That looks like the two are pretty interchangeable. When would I prefer
> one
> > over the other?
> >
> >
>
> ($) has lower precedence (it was introduced for that reason I belive).
>
> Prelude> :info ($)
> ($) :: (a -> b) -> a -> b -- Defined in GHC.Base
> infixr 0 $
>
> Please take a look at:
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1/Prelude.html#v:-36-
>
> From the docs:
>
> "Application operator. This operator is redundant, since ordinary
> application (f x) means the same as (f $ x). However, $ has low,
> right-associative binding precedence, so it sometimes allows parentheses
> to be omitted..."
>
> Emanuel
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130213/787655cb/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 12 Feb 2013 17:05:18 -0500
From: Brandon Allbery <[email protected]>
Subject: Re: [Haskell-beginners] Parsec simple question
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID:
<cakfcl4ujp0qrynj5p6wylju+ja_vnxffj_edkskuxeyejqk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Feb 12, 2013 at 4:38 PM, Sean Cormican <[email protected]>wrote:
> name :: Expression
> name = ID "string"
>
> number :: Expression
> number = Num 123
>
> whileParser :: Parser Expression
> whileParser = whiteSpace >> expr8
>
> expr8 :: Parser Expression
> expr8 = name
> <|> number
>
You have defined name to be an Expression. But <|> composes *parsers*, not
expressions. To create a Parser Expression, you would be composing (Parser
Expression)s, not simply (Expression)s; so you don't want "name" to be
simply an Expression, but a Parser that parses an input String and produces
an Expression, something like
name :: Parser Expression
name = ID <*> identifier -- parse an identifier, wrap it in an ID
number :: Parser Expression
number = Num <*> integer -- parse an integer, wrap it in a Num
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130212/664b7777/attachment-0001.htm>
------------------------------
Message: 3
Date: Tue, 12 Feb 2013 17:35:20 -0800
From: Paul Higham <[email protected]>
Subject: Re: [Haskell-beginners] f . g or f g or f $ g?
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
An example that helped me understand the utility of the $ operator is as
follows:
suppose that we have a list of functions
fs :: [a -> b]
fs = [f1, f2, ..., fk]
and a list of arguments
as :: [a]
as = [a1, a2, ..., ak]
and we want to produce the list
[f1(a1), f2(a2), ..., fk(ak)], or equivalently [f1 a1, f2 a2, ..., fk
ak],
this can be done using the $ operator via
zipWith ($) fs as
simply because it makes the function application explicit.
::paul
On 2013-02-12, at 13:44 , mukesh tiwari wrote:
> You can write (f . g) x as f . g $ x so for me, it's avoiding extra
> parenthesis.
>
> Mukesh
>
> On Wed, Feb 13, 2013 at 2:53 AM, Emanuel Koczwara <[email protected]>
> wrote:
> Hi,
>
> Dnia 2013-02-12, wto o godzinie 22:09 +0100, Martin Drautzburg pisze:
> > On Friday, 1. February 2013 23:02:39 Ertugrul S?ylemez wrote:
> >
> > > (f . g) x = f (g x)
> >
> >
> > so (f . g) x = f $ g x
> >
> > right?
> >
> > That looks like the two are pretty interchangeable. When would I prefer one
> > over the other?
> >
> >
>
> ($) has lower precedence (it was introduced for that reason I belive).
>
> Prelude> :info ($)
> ($) :: (a -> b) -> a -> b -- Defined in GHC.Base
> infixr 0 $
>
> Please take a look at:
> http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1/Prelude.html#v:-36-
>
> From the docs:
>
> "Application operator. This operator is redundant, since ordinary
> application (f x) means the same as (f $ x). However, $ has low,
> right-associative binding precedence, so it sometimes allows parentheses
> to be omitted..."
>
> Emanuel
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130212/d466c238/attachment-0001.htm>
------------------------------
Message: 4
Date: Tue, 12 Feb 2013 21:09:17 -0500
From: Michael Orlitzky <[email protected]>
Subject: Re: [Haskell-beginners] Beginners Digest, Vol 56, Issue 20
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 02/12/2013 02:14 PM, Brent Yorgey wrote:
> Hi Patrick,
>
> I would highly recommend
>
> Jeremy Gibbons, "Calculating Functional Programs".
It looks to be available from the author's site:
http://www.cs.ox.ac.uk/jeremy.gibbons/publications/acmmpc-calcfp.pdf
------------------------------
Message: 5
Date: Wed, 13 Feb 2013 04:18:08 +0100
From: Ertugrul S?ylemez <[email protected]>
Subject: Re: [Haskell-beginners] f . g or f g or f $ g?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
mukesh tiwari <[email protected]> wrote:
> You can write (f . g) x as f . g $ x so for me, it's avoiding extra
> parenthesis.
Here comes my usual lecture: The ($) operator can be harmful when
explicitly used to avoid extra parentheses, because it makes code flat.
Besides grouping function application parentheses also serve a
readability purpose, about the same one as indentation. In other words,
think twice before you overuse ($).
Background: In some of my projects I have noticed that to revisit old
code I had an easier time rewriting some of my ($) applications back to
parentheses to make the code structure more apparent and easier for the
eye, particularly when both sides of ($) were long and multiple ($)s
were involved. But even in very simple cases parentheses just look much
nicer. Compare
print $ sin x
with
print (sin x)
The latter just looks nicer, at least to my eyes. Of course there are
cases when ($) is really preferred, like when one side is very long,
perhaps multi-lined, and the other is very short:
log $ "Client connecting from " ++ hostname
or:
withSteak $ \steak -> do
getHungry
eatWith cutlery steak
beHappy
But then of course in many cases you get hungry long before you get the
steak:
getHungry
withSteak (eatWith cutlery)
beHappy
Greets,
Ertugrul
--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130213/d281c260/attachment-0001.pgp>
------------------------------
Message: 6
Date: Wed, 13 Feb 2013 04:00:26 +0000
From: Mateusz Kowalczyk <[email protected]>
Subject: Re: [Haskell-beginners] f . g or f g or f $ g?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15
A less obvious interpretation is to treat ($) as `id'.
(f . g) x = f $ g x = f (id g x) = f (g x)
Bah, we can even illustrate that ($) is simply an infix identity function:
Prelude> map ((flip id) 2) [\x -> x - 3]
[-1]
Prelude> map (`id` 2) [\x -> x - 3]
[-1]
Prelude> map ($ 2) [\x -> x - 3]
[-1]
I just wanted to throw this out there as I found this out recently
myself and found it fairly useful. I believe someone else already posted
a link about pointless style.
On 12/02/13 21:09, Martin Drautzburg wrote:
> On Friday, 1. February 2013 23:02:39 Ertugrul S?ylemez wrote:
>
>> (f . g) x = f (g x)
>
>
> so (f . g) x = f $ g x
>
> right?
>
> That looks like the two are pretty interchangeable. When would I prefer one
> over the other?
>
>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 56, Issue 23
*****************************************
