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. general structuring of "foreach" logic in IO (John M. Dlugosz)
2. what is "Gesh"? (Re: function not working as expected, type
issues) (John M. Dlugosz)
3. Re: general structuring of "foreach" logic in IO
(Magnus Therning)
4. parsing exif file: binary, binary-strict, or cereal?
(Emmanuel Touzery)
----------------------------------------------------------------------
Message: 1
Date: Sat, 12 Apr 2014 08:29:09 -0500
From: "John M. Dlugosz" <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] general structuring of "foreach" logic in
IO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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?
Thanks,
-John
------------------------------
Message: 2
Date: Sat, 12 Apr 2014 23:02:19 -0500
From: "John M. Dlugosz" <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] what is "Gesh"? (Re: function not working
as expected, type issues)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 4/9/2014 3:45 AM, Gesh wrote:
> Thank you for explaining the problem you're trying to solve instead of Gesh
> problem you're facing.
Is that some jargon I'm missing? Hmm, I see that's your name and email address
too.
------------------------------
Message: 3
Date: Sun, 13 Apr 2014 08:48:35 +0200
From: Magnus Therning <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] general structuring of "foreach"
logic in IO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140413/bdd84de6/attachment-0001.sig>
------------------------------
Message: 4
Date: Sun, 13 Apr 2014 10:21:12 +0200
From: Emmanuel Touzery <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [Haskell-beginners] parsing exif file: binary, binary-strict,
or cereal?
Message-ID:
<CAC42Re=-Bx_3x=+gnhh3tu3fofnqdwgvtzbydoh+pmfpzmc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I could not find a pure haskell library to parse EXIF so I wrote one
(pretty basic so far):
https://github.com/emmanueltouzery/hsexif
I wrote it with binary-strict. I also considered binary, but I would like
the library not to throw an exception if the file that it's given is not a
JPEG or is a JPEG without EXIF, but rather return an Either. I didn't
manage to do that with binary (I mean I could offer an IO monad wrapper
with try* but to do that even if you give me a lazy bytestring, when it
could be done only with pure code, is annoying).
It annoys me to load the full JPEG in memory just to parse its EXIF
though. Then again with binary I'd have to be pretty careful with
strictness annotations and so on, although parsing the EXIF is going to be
fast and it won't contain that much data. Still, I want the lazy bytestring
holding the JPEG file to be released ASAP. It'd be a shame to have it lying
in memory, together with holding the JPEG file open until the library
caller actually makes use of the EXIF contents...
And then I realized that binary-strict was last updated in 2010, it seems
cereal is recommended for strict binary file parsing nowadays.
So, what should I do? Leave it as it is? Port to cereal? Port to binary?
Otherwise I did write this because I'd like to make a program to parse
EXIF file which will have to run also on windows. The haskell exif parsing
library that I could find uses the C library libexif, which is going to get
complicated to get running on windows. Plus it was fun :-)
Thanks,
Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140413/5dae8eac/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 70, Issue 26
*****************************************
