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: Global variables (Ertugrul Soeylemez)
2. Re: Global variables (Michael Snoyman)
3. Re: A first try (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Jun 2011 07:35:08 +0200
From: Ertugrul Soeylemez <[email protected]>
Subject: Re: [Haskell-beginners] Global variables
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
Michael Snoyman <[email protected]> wrote:
> Though in this case, you can go with the cheaper IORef, since
> (presumably) the only operation is going to be incrementing the
> counter. Just be sure to use atomicModifyIORef[1].
I never recommend (or mention for that matter) IORefs in the beginner
list. Also I think than an atomically modified IORef is not necessarily
faster. TVars are optimized for that kind of operation.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
------------------------------
Message: 2
Date: Thu, 30 Jun 2011 08:40:53 +0300
From: Michael Snoyman <[email protected]>
Subject: Re: [Haskell-beginners] Global variables
To: Ertugrul Soeylemez <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jun 30, 2011 at 8:35 AM, Ertugrul Soeylemez <[email protected]> wrote:
> Michael Snoyman <[email protected]> wrote:
>
>> Though in this case, you can go with the cheaper IORef, since
>> (presumably) the only operation is going to be incrementing the
>> counter. Just be sure to use atomicModifyIORef[1].
>
> I never recommend (or mention for that matter) IORefs in the beginner
> list. ?Also I think than an atomically modified IORef is not necessarily
> faster. ?TVars are optimized for that kind of operation.
I understand why you avoid mentioning IORef, but I personally find it
a simpler solution to the problem, and avoids the need for a beginner
to jump into STM. I'd be very interested in seeing if TVars can be as
fast as IORefs for this kind of stuff; I know switching the timeout
code in Warp to use atomic IORef operations produced a *huge* speed
gain, but I may be conflating multiple code changes together.
Michael
------------------------------
Message: 3
Date: Thu, 30 Jun 2011 11:04:53 +0200
From: Heinrich Apfelmus <[email protected]>
Subject: Re: [Haskell-beginners] A first try
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
David Place wrote:
> On Jun 29, 2011, at 4:30 AM, Heinrich Apfelmus wrote:
>
>> It is still possible to write programs that return unexpected _|_,
>> but they violate a clear conceptual guideline ("only fully
>> evaluated values may escape the scope of withFile ").
>
> I wonder. If that is the behavior you desire, why not just call
> deepseq on the value before you return it to guarantee it.
Hm. The idea was that while evaluating the return value in full is a
sufficient requirement, it is not a necessary requirement. The return
value may contain unevaluated expressions as long as the input stream is
being forced. Example:
do
s <- hGetContents h
let x = take 10 s `deepseq` [reverse . drop 3 $ take 7 s]
evaluate x
hClose h
Evaluating x to weak head normal form will force the first 10
characters of the input, but x will still contain unevaluated
expressions. (This is what Iteratees do: they force the input without
forcing the return value.)
But you are probably right, it's better to give guarantees. The behavior
above can still be simulated with a broken deepseq instance.
data Lazy a = Lazy a
data NFData (Lazy a) where
rnf _ = () -- broken on purpose
This way, breaking the guarantee takes more effort than not breaking it,
as it should be.
>> Granted, Iteratees make it impossible to write such programs, but
>> they come with the terrible price of code duplication.
>
> I don't really understand this objection, though. Won't any iteratee
> library provide all those functions? The user shouldn't have to
> write them. In this way, it is certainly no worse than the
> duplication brought about by ByteStrings. Also, isn't that the point
> of the ListLike class?
I think the ListLike class demonstrates very well that there will
always be useful list functions that are not provided by an existing
API. :) Also note that the ListLike class from the ListLike package
doesn't work for Iteratees, they have to provide their own functions and
so on. At some point, the count of different implementations for, holy
lambda, *lazy lists* simply becomes ridiculous. ;)
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 36, Issue 84
*****************************************
