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: How do I use Guards in record syntax? (Bob Ippolito)
2. Re: general structuring of "foreach" logic in IO
(Patrick Wheeler)
3. Re: recursive 'let' ? (Patrick Wheeler)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Apr 2014 00:35:58 -0700
From: Bob Ippolito <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How do I use Guards in record syntax?
Message-ID:
<cacwmpm8-voshoc9-jzd42ypugkuzsyo904htm-1+oh0jft0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You can't use guards in record syntax, but you could use `case` here
instead of `let`, or just write a function of type `String -> BuyOrSell`
and use that.
On Sun, Apr 13, 2014 at 11:03 PM, Dimitri DeFigueiredo <
[email protected]> wrote:
>
> I'm having some trouble understanding where I can or cannot use guards
> inside record syntax. I'm writing a simple conversion routine, but I am not
> able to write it without inserting an extra let. Do I need a let expression
> here? Am I missing something?
>
> --------------
> data OldTrade = OldTrade {
> oldprice :: Double ,
> oldamount :: Double ,
> oldbuysell :: String -- "buy", "sell" or ""
> } deriving( Eq, Show)
>
>
> data BuyOrSell = Buy | Sell | Unknown deriving(Eq, Show)
>
> data Trade = Trade {
> price :: Double ,
> amount :: Double ,
> buysell :: BuyOrSell
> } deriving( Eq, Show)
>
> convert :: OldTrade -> Trade
>
> convert ot = Trade { price = oldprice ot,
> amount = oldamount ot,
> buysell = let x | oldbuysell ot == "buy" = Buy
> | oldbuysell ot == "sell" = Sell
> | otherwise = Unknown
> in x
> }
>
> -- how do I eliminate the 'let' expression here?
> -- I wanted to write something like:
> --
> -- buysell | oldbuysell ot == "buy" = Buy
> -- | oldbuysell ot == "sell" = Sell
> -- | otherwise = Unknown
>
> --------------
>
> Thanks!
>
> Dimitri
>
>
>
>
> _______________________________________________
> 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/20140414/e5c03100/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 14 Apr 2014 04:34:47 -0500
From: Patrick Wheeler <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] general structuring of "foreach"
logic in IO
Message-ID:
<CAAo_BYZJL+N7HW+gGm0jKjmac1s9OznyfFU=7ogdgownqew...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
@John
It looks like you are looking for `forM_` from Control.Monad:
http://hackage.haskell.org/package/base-4.7.0.0/docs/Control-Monad.html#v:forM_
That way you can write code that looks like:
main = do
myargs <- getArgs
forM_ myargs $ \s -> do
putStrLn s
putStrLn $ "Second string" ++ s
This is just `mapM_` with the its two parameters fliped. `forM_` is defined
in a an idiomatic fashion, with the `flip`(prelude function) function.
Definition of forM_
http://hackage.haskell.org/package/base-4.7.0.0/docs/src/Control-Monad.html#forM_
Magnus solution has been used so often by some people that some have
created idioms around it.
om f m x = m >>= flip f x
main = do
om forM_ getArgs $ \s -> do
putStrLn s
putStrLn $ "Second string: " ++ s
You can read the discussion around om:
http://www.reddit.com/r/haskell/comments/1i2zmq/a_useful_function_om/
Hope that helps.
Patrick
On Sun, Apr 13, 2014 at 1:48 AM, Magnus Therning <[email protected]>wrote:
> On Sat, Apr 12, 2014 at 08:29:09AM -0500, John M. Dlugosz wrote:
> > This works:
> >
> > main = do
> > myargs <- getArgs
> > mapM_ (\s -> putStrLn s ) myargs
> >
> > and imagine that the "body" will be substantial rather than just a
> putStrLn.
> > My gut instinct is that the code ought to be arranged as:
> >
> > <any needed keywords or punctuation> and <the collection of items>
> > <body to perform for every element
> > ...
> > ...
> > >
> >
> > Meanwhile, there is no need to name the result of getArgs into myargs.
> >
> > So, getArgs is of type IO [String], and I want to apply that in the
> > manner of a list. Without the Monad wrappers, plain
> > map ( blah ) strings
> > could be ( blah ) <$> strings, and in this particular case I don't
> > see a reversed-arg version, although there is one for <*> (as <**>).
> > But, for monad stuff in general there are reversed arrows for
> > (most?) everything, and that's where I'm heading.
> >
> > So the first question is, how do I do the equivalent
> > map-as-nondeterministic-apply when the strings is further wrapped in
> > IO, as is the function being applied.
> >
> > getArgs >>= mapM_ (\s -> putStrLn s )
> >
> > does double-duty of moving the argument from last place to the left,
> > as it makes use of eta reduction. Because I have two things going
> > on (list applicative and IO monad) I'm losing the slickness of using
> > applicative syntax. Is there a nice way to make these work
> > together?
> >
> > And more generally, how would you write such a construct? I'm
> > naturally biased with my knowledge in other languages, so maybe
> > there's a completely different "normal" way of approaching this?
>
> I'm not entirely sure I get what you are asking for, but I'll take a
> stab and just let me know if I'm completely off the mark.
>
> If all you want is keep the 'string generator' on the right-hand side,
> then you have (=<<):
>
> mapM_ putStrLn =<< getArgs
>
> Personally I often like keeping the 'string generator' on the left
> (i.e. using (>>=) because when the expression to be mapped grows it
> allows this structuring of the code:
>
> getArgs >>= mapM_ $ \ s -> do
> ...
>
> /M
>
> --
> Magnus Therning OpenPGP: 0xAB4DFBA4
> email: [email protected] jabber: [email protected]
> twitter: magthe http://therning.org/magnus
>
> Perl is another example of filling a tiny, short-term need, and then
> being a real problem in the longer term.
> -- Alan Kay
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
--
Patrick Wheeler
[email protected]
[email protected]
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140414/666d84ad/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 14 Apr 2014 05:09:20 -0500
From: Patrick Wheeler <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] recursive 'let' ?
Message-ID:
<caao_byzb6uzn8jxh8cdyy9w38jopxpex1t4d5rbrvkju1bw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
@John
Top level values have the attributes that you describe, recursion, mutual
recursion are possible.
So by using `let` and `where`, with out knowing any additional rules or
information, we can define values and functions which can be locally
scoped. Reducing the number of top level values by using locally scoped
vales often makes it easier to think about a problem.
You concern seems to be focused on the mutual recursion aspect however. Why
it is it useful in general? It allows for problems to be broken down in to
sub problems and solved separately.
With out mutually recursion or something similar if you had a problem that
need to recurse in two different ways, each which some times depended on
the other you would have to write it all in one large function.
An example where this is used in serious cod would be pipes and conduit.
Both handle stream processing of data.
Mutual recursion between (>>~) and (+>>)
http://hackage.haskell.org/package/pipes-4.1.1/docs/src/Pipes-Core.html#%3E%3E~
Look at the goRight and goLeft functions that are locally scoped with
`where` in either the `pipe` or `pipeL` functions.
https://hackage.haskell.org/package/conduit-1.1.0.1/docs/src/Data-Conduit-Internal.html#Pipe
So can help as a tool to break some problems in to subproblems and it is
used in serious code in Haskell
Patrick
On Fri, Apr 11, 2014 at 10:28 AM, Magnus Therning <[email protected]>wrote:
> On Thu, Apr 10, 2014 at 07:12:25PM -0500, John M. Dlugosz wrote:
> > I understand that the definitions introduced by 'let' can be
> > recursive, even mutually recursive among several names. Why would
> > you want to do that? I saw contrived examples, and wonder why the
> > authors never show a realistic example.
> >
> > let b = f a c
> > c = f a b
> > in ...
> >
> > I see that makes sense in light of lazy evaluation: b is really an
> > alias for a (recursive) function, not a value that needs to find
> > fixed points.
> >
> > Is this used for common idioms and problem-solving approaches in
> > Haskell?
>
> I can't really point to any idiomatic use, or problem-solving
> approaches, but it is a terribly useful feature since one of the
> effects is that the order of introducing functions/values isn't
> significant. So you are free to write and structure your code in the
> manner that makes most sense to you.
>
> Having just ventured back into OCaml and dipping my toes in F# I
> immediately ran into errors caused by their non-recursive `let`, and
> the requirement to introduce values/types before use.
>
> /M
>
> --
> Magnus Therning OpenPGP: 0xAB4DFBA4
> email: [email protected] jabber: [email protected]
> twitter: magthe http://therning.org/magnus
>
> The results point out the fragility of programmer expertise: advanced
> programmers have strong expectations about what programs should look like,
> and when those expectations are violated--in seemingly innocuous
> ways--their performance drops drastically.
> -- Elliot Soloway and Kate Ehrlich
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
--
Patrick Wheeler
[email protected]
[email protected]
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140414/ce5a6a2c/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 70, Issue 28
*****************************************
