Re: [Haskell-cafe] State monad strictness - how?
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 considered a serious bug in the library. It has been reported on numerous occasions over the years, but it has still not been fixed. At the very least, the two should be consistent. I would much prefer for them both to be lazy. I have written a lot of code that depends on that; it is the natural assumption in Haskell that everything is lazy by default, except seq, IO, and their friends. The obvious solution would be to have available both a lazy and a strict version of each monad: State, State', StateT, and State'T (or some such), with functions to convert between them. It is trivial to implement that in the current library. If someone can come up with a more elegant solution right away, that would be great. (Iavor - do you have a solution?) Otherwise, I think we have waited long enough. Let's implement the simple fix. This bug is a major inconvenience to users of this library. (try 100) overflows the stack. In the current situation, you can use where final = runIdentity $ execStateT prog (0::Int) ... tick :: (Num a, MonadState a m) = m a ... Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] State monad strictness - how?
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 be lazy. 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 - for one who knows what he wants - with a Lazy prefix, e.g. LazyST, LazyState... -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] State monad strictness - how?
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 - for one who knows what he wants - with a Lazy prefix, e.g. LazyST, LazyState... Well, as long as both are provided, that is fine with me. But I do not think that laziness in monad methods is a reason for beginners' confusion. First of all, it is natural to get a little confused about strictness at the beginning. I'm not sure it happens more often with monads than anywhere else. If there is more confusion about strictness with monads, it is because of the fact that many introductions/tutorials confuse all monads with IO. They say something like: So how do you create side effects in the real world? That is what monads are for. No, no, no! That is what ** IO ** is for. Most monads are pure! In fact, I think making the default strict will create more confusion. We should help beginners to understand right from the start that do-notation is not a procedure of commands for the computer to carry out. It is just a special syntax for defining functions. We use it when it is more natural to describe the effect of a function in a step-by-step style, just as happens sometimes in mathematics. But the compiler is under no obligation to follow our steps literally. Except with IO - when dealing with the real world, we need to be able to specify the exact order in which things happen. ST represents using physical memory as a fast storage device. So it is really IO in disguise. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] State monad strictness - how?
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 carries around? What about the value component? I think the answer to these questions are the same as for monadic strictness above: both strict and lazy variants are useful. Now, the challenge here is to design a library which doesn't explode in size from all the various possibilities for strictness or laziness. In fact I did once bite the bullet and came up with a library that does all this. Though I haven't released it publicly yet. I never took the time to polish the code to the point where I wouldn't be embarrassed about showing it to others. If you kick me hard enough I might release the library. Cheers, Josef On 1/10/07, Yitzchak Gale [EMAIL PROTECTED] wrote: 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 - for one who knows what he wants - with a Lazy prefix, e.g. LazyST, LazyState... Well, as long as both are provided, that is fine with me. But I do not think that laziness in monad methods is a reason for beginners' confusion. First of all, it is natural to get a little confused about strictness at the beginning. I'm not sure it happens more often with monads than anywhere else. If there is more confusion about strictness with monads, it is because of the fact that many introductions/tutorials confuse all monads with IO. They say something like: So how do you create side effects in the real world? That is what monads are for. No, no, no! That is what ** IO ** is for. Most monads are pure! In fact, I think making the default strict will create more confusion. We should help beginners to understand right from the start that do-notation is not a procedure of commands for the computer to carry out. It is just a special syntax for defining functions. We use it when it is more natural to describe the effect of a function in a step-by-step style, just as happens sometimes in mathematics. But the compiler is under no obligation to follow our steps literally. Except with IO - when dealing with the real world, we need to be able to specify the exact order in which things happen. ST represents using physical memory as a fast storage device. So it is really IO in disguise. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What happened to Haskell original goals?
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 me learning this really cool language. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] State monad strictness - how?
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. Take the state monad for example. Should it be strict or lazy in the state that it carries around? What about the value component? I think the answer to these questions are the same as for monadic strictness above: both strict and lazy variants are useful. Are those really needed? Can't the strictness of the state be fully controlled by seq with runState, get, and put, and by choosing lazy or strict =? And similarly with value? As opposed to =, where there is no way to control its strictness from outside the Monad instance declaration. Now, the challenge here is to design a library which doesn't explode in size from all the various possibilities for strictness or laziness. The same challenge exists in many of the Data.* libraries. I think this is very important. In fact I did once bite the bullet and came up with a library that does all this. Though I haven't released it publicly yet. I never took the time to polish the code to the point where I wouldn't be embarrassed about showing it to others. If you kick me hard enough I might release the library. My boot is not long enough :). But I would love to see what you did. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] State monad strictness - how?
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 control over strictness is =, like Dean's example.
Yes. For most uses this finer control of strictness is just overkill.
But in the rare cases when you really need this tweakability then it's
a royal pain if you don't have it.
Take the state monad for example. Should it be strict or
lazy in the state that it carries around? What about the value
component? I think the answer to these questions are the same as for
monadic strictness above: both strict and lazy variants are useful.
Are those really needed? Can't the strictness of the state be
fully controlled by seq with runState, get, and put, and by
choosing lazy or strict =? And similarly with value?
Yes, you're right. But it wouldn't be very convenient, would it?
Sometimes I find that I want strict state by default and then I don't
want to sprinkle my code with seqs. Furthermore this extra level of
control is not that difficult to implement in a library.
Now, the challenge here is to design a library which doesn't explode
in size from all the various possibilities for strictness or laziness.
The same challenge exists in many of the Data.* libraries.
I think this is very important.
Indeed.
In fact I did once bite the bullet and came up with a library that
does all this. Though I haven't released it publicly yet. I never took
the time to polish the code to the point where I wouldn't be
embarrassed about showing it to others.
If you kick me hard enough I might release the library.
My boot is not long enough :). But I would love to see
what you did.
:-) Ok, I've put some files under the following url:
http://www.cs.chalmers.se/~josefs/monadlib/
It might need some explanation since I use the module system quite
heavily. For a monad such as the state monad the hierarchy looks like
this:
* Control.Monad.State.Base contains the type declaration and basic
functionality, but NOT instances of the monad class.
This module is not exposed.
* Control.Monad.State.Lazy
* Control.Monad.State.Strict
Contains instances for monad classes.
* Control.Monad.State is supposed to be the default and just reexports
Control.Monad.State.Strict.
Furthermore, again taking the state monad as example, the monad is
parameterized on the type of pair used in the definition of the monad.
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 control over strictness for
state and value. Data.Pair provides various pair for this purpose.
Enjoy,
Josef
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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, but StatT Int Id is lazy. One way to get a strict
state monad with monadLib is like this:
import MonadLib
data Lift a = Lift { runLift :: a }
instance Monad Lift where
return x = Lift x
Lift x = f = f x
strict = runLift $ runStateT 2 $
do undefined
return 5
lazy = runId $ runStateT 2 $
do undefined
return 5
The difference between those two is that strict == undefined, while
lazy = (5,undefined).
Unfortunately the monad Lift is not part of monadLib at the moment
so you have to define it on your own, like I did above, but I think
that this is a good example of when it is useful, so I will probably
add it to the next release.
-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: state of HaXml?
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 close the file (via the finalizer) before reaping the memory associated with the handle. That's not the point. The GC will only close the file when the heap is under pressure. It does not aggressively close the file, so the file may stay open for longer than the user likes. For a read-only operation, this shouldn't matter, however on some platforms an open file handle can prevent deletion of the file. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: state of HaXml?
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 FILE_SHARE_DELETE to CreateFile, if your Haskell runtime is using the win32 file API. The semantics are a bit strange, but it's less hostile than the default behaviour. If your favourite runtime is going through stdio, you're stuck (the strong-stomached can use CreateFile, then turn the handle into a FILE*, but this behaves peculiarly). b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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 control over strictness for
state and value.
Beautiful!
Iavor Diatchki wrote:
The state transformer inherits its behavior from the underlying
monad. For example: StateT Int IO is strict, but StateT Int Id
is lazy.
Fantastic!
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).
Now let's attack Data.* libraries...
-Yitzchak
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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, State', StateT, and State'T (or some such), with functions to convert between them. It is trivial to implement that in the current library. First, thanks for the very helpful reply explaining the situation. Second, how would one know that State is lazy and StateT is strict? I don't see that in the Haddock documentation. 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 strictness? Dean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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 strictness? Dean The r0 and rwhnf and rnf from http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Parallel-Strategies.html parameterize strictness. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] restricted existential datatypes
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 way of pointing at the dictionary is possible using GADT: data ShowCxt a where Sh :: Show a = ShowCxt a f :: forall cxt . (Contains cxt ShowCxt) = Box cxt - String f (Box (x :: a)) = case subDict (dict :: cxt a) of Sh - show x The above compiles in GHC HEAD (6.6 is unfortunately not enough). Regards, Zun. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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, for the continuation transformer). as usual, feedback is welcome. -iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellForge?
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 necessary for your program to run 5. A build system that takes a program name and builds/installs it on your system For #1, web hosting with ssh access is really cheap and easy. I've seen hosting as low as $1/month. If people here are really unsatisfied with all the hosting out there. I am happy to provide simple darcs hosting on one of my servers for a pittance. For #2, google works pretty well. Is there functionality we need that it misses? For #3, I made a start with http://searchpath.org/default.map. If people want me to add other packages to that namespace let me know. Conceptually, the namespace is federated because you can combine that file with other files to build a composite namespace. For #4, I made a start with SearchPath (available at http://searchpath.org). Searchpath looks at the source of the haskell module passed on on the command line and then does recursive import chasing accross the internet using the set of module maps passed on the command line. Currently, is does not handle well modules that use cpp to import code and it doesn't handle at all modules that have dependencies on C libraries that are not already local and on the path. For #5, the platform specific package managers seem like the correct solution. Perhaps something important is gained from integrating some subset of 1-5. Perhaps the particular implementations of #1-5 are lacking in some manner that is not apparent. Perhaps we just need community acceptance for a particular version of each of these. -Alex- Michael T. Richter wrote: On Mon, 2007-08-01 at 18:19 +0100, Sven Panne wrote: For example, if I want to install Rails (ruby web-app framework), I just type: gem install rails It's pretty slick. How does this work with the native packaging mechanism on your platform (RPM, ...)? Does it work behind it's back (which would be bad)? It doesn't. It is its own Ruby-specific packaging mechanism. Let's assume that rails needs foo and bar as well, which are not yet on your box. Does gem install transitively get/update all dependecies of rails? Well rails needs dozens of libraries, seemingly, and it can be told to collect all dependencies. (If it isn't told one way or another, it asks.) This is true, however, iff the dependencies are all gems themselves. If you need a third-party library installed that's not wrapped in a gem, you have to use your usual packaging system to get it. (Being an Ubuntu user, I use aptitude.) Overall, I like the gems approach. The Ruby packages for debian-alikes are almost invariably out of date and building a lot of these Ruby enhancements is a pain in the posterior. If I want a stable version of a given component, I'll use aptitude (or RPM or whatever) and live with it being out of date. If I want the latest and greatest, however, I'll stick to the gems. Since gems can be installed and deleted just like aptitude's packages can be (and just as cleanly) it really isn't that hard an approach. -- *Michael T. Richter* /Email:/ [EMAIL PROTECTED], [EMAIL PROTECTED] /MSN:/ [EMAIL PROTECTED], [EMAIL PROTECTED]; /YIM:/ michael_richter_1966; /AIM:/ YanJiahua1966; /ICQ:/ 241960658; /Jabber:/ [EMAIL PROTECTED] /[Blacks] ... are inferior to the whites in the endowments both of body and mind./ *--Thomas Jefferson* ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
...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: (a, s') - runStateT m s The tuple pattern-match causes the strictness. That appears accidental, so it seems to be just an honest bug. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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 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 like this: [strict pseudo-monad] This (like StateT) gives you strictness in the pair, but doesn't give the strictness in the state that the original poster wanted. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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. They are surprising and surprisingly powerful. A haskell that did no more than scheme would not be as interesting. I may be subject to selection bias, but I haven't seen so many references to a language in unexpected contexts since smalltalk in the mid 80's. I don't think that's because it's a language that behaves the way someone coming from another language expects. On 1/10/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: 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 be lazy. 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 - for one who knows what he wants - with a Lazy prefix, e.g. LazyST, LazyState... -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad strictness - how?
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 like this: [strict pseudo-monad] This (like StateT) gives you strictness in the pair, but doesn't give the strictness in the state that the original poster wanted. Once we have this kind of strictness, then the programmer has control over the state. For example, they can define: setStrict x = seq x (set x) ex3 = runLift $ runState 2 $ setStrict undefined return 5 ex4 = runId $ runState 2 $ setStrict undefined return 5 In these examples ex3 == undefined but ex4 = (5,undefined). -Iavor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] UDP client/server
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
