Dean Herington wrote:
I can't seem to figure out how to achieve strictness
in the context of the State monad.
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
It seems to me that this should clearly be
Hello Yitzchak,
Wednesday, January 10, 2007, 12:02:25 PM, you wrote:
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
At the very least, the two should be consistent. I
would much prefer for them both to
Hi Bulat,
I wrote:
[State and StateT] should be consistent. I
would much prefer for them both to be lazy.
Bulat Ziganshin wrote:
imho, lazy monads (as any other lazy things) is a source of beginner's
confusion. therefore it may be better to provide default monads as strict
and lazy ones -
Yitzchak,
I agree with you that both lazy and strict monads are important and
that we should have both options in a monad library.
But the fun doesn't end there. There are other strictness properties
to consider. Take the state monad for example. Should it be strict or
lazy in the state that it
I remember reading avoid success at all costs
somewhere. I miss the old days when I could read
all messages in this list. Today, I can hardly
keep up with a few of the most interesting
threads.
Good programming for all you guys in 2007. Thanks
for your support and comments, and for helping
Hi Josef,
Josef Svenningsson wrote:
...the fun doesn't end there. There are other strictness properties
to consider.
Could be. But after using mtl heavily for a few years now,
I find that in practice the only one where have felt the need
for control over strictness is =, like Dean's example.
On 1/10/07, Yitzchak Gale [EMAIL PROTECTED] wrote:
Hi Josef,
Josef Svenningsson wrote:
...the fun doesn't end there. There are other strictness properties
to consider.
Could be. But after using mtl heavily for a few years now,
I find that in practice the only one where have felt the need
for
Hello,
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
There is no such distinction in monadLib. The state transformer
inherits its behavior from the underlying monad. For example: StateT
Int IO is strict,
On 1/10/07, Malcolm Wallace [EMAIL PROTECTED] wrote:
Actually, I'm pretty sure that most Haskell RTS implementations have a
finalizer attached to all file handles. Once the file handle is no
longer reachable from the program graph (even if its data has not been
fully consumed), the GC will
Taral wrote:
For a read-only
operation, this shouldn't matter, however on some platforms an open
file handle can prevent deletion of the file.
You'd be referring to Windows, then, where you can't rename or remove a
file if someone has opened it.
A partial defence against this is to pass
Wow! Now we are talking!
Josef Svenningsson wrote:
So instead of:
newtype State s a = State { runState :: (s - (a, s)) }
we have:
newtype StateP p s a = StateP { runStateP :: (s - p a s) }
Now, instantiating this with different pair types with different
strictness properties will give us total
At 11:02 AM +0200 1/10/07, Yitzchak Gale wrote:
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
[...]
The obvious solution would be to have available
both a lazy and a strict version of each monad: State,
Dean Herington wrote:
Third, isn't it a continuum rather than a binary choice between lazy and
strict? In my example, I used ($!) in the definition of (=), but
that's just one flavor of strictness that was appropriate to my
example. Is there some way to parameterize this degree of
Misha Aizatulin wrote:
The question I'd like to ask is whether there is some trickery to
circumvent this problem. In the f function I'd like to be able to hint
to the compiler that I want Show to be derived from cxt which is
attached to the Box, but I see no way of doing that.
An explicit
hi,
I'm drooling. When can we get stuff like this into MTL?
And maybe it is finally time for me to bite the bullet and
try out monadLib again (is it still CPS? gulp).
version 3 (the current version) implements the transformers in the
usual way (e.g., as in mtl) so no cps (except, of course,
Let's be really specific about what we want to have in this regard:
1. repo hosting
2. repo searching
3. A shared/federated name space mapping module names to the URLs of
repos that implement those modules
4. A dev system that uses the name space to download and import chase
the modules
...how would one know that State is lazy and StateT is strict?
I don't see that in the Haddock documentation.
You're right, it is not in the docs. I don't think anyone would
have planned it that way. StateT is strict only because there
happens to be a line in a do-expression that looks like:
On Wed, Jan 10, 2007 at 10:02:36AM -0800, Iavor Diatchki wrote:
[Yitzchak Gale:]
Unfortunately, the current situation is that State is only
available as a lazy monad, and StateT is only available
as a strict monad.
There is no such distinction in monadLib. The state transformer
inherits
haskell is the standard lazy functional language, so strictness ought
to be called out. e.g. StateStrict rather than StateLazy.
The traction that haskell is starting to get (and why I'm spending
time learning it and following haskell-cafe) is not because its
semantics are unsurprising to newbies.
Hello,
On 1/10/07, Ross Paterson [EMAIL PROTECTED] wrote:
There is no such distinction in monadLib. The state transformer
inherits its behavior from the underlying monad. For example: StateT
Int IO is strict, but StatT Int Id is lazy. One way to get a strict
state monad with monadLib is
Hello,
Does anyone know where I can find a simple UDP client/server written in
Haskell?
Something along the lines of an echo server would do.
Thanks
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
21 matches
Mail list logo
