[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Neil Mitchell schrieb: Hi (There's still no good introduction to Monads, for example. One that's understandable for a programmer who knows his Dijkstra well but no category theory. And a few other things.) I grasped this one first time round: http://haskell.org/haskellwiki/Monads_as_containers That one escaped me. Thanks. And Haskell let's you serialise thunks just fine (use Yhc), Yhc explicitly say "not production-ready" on the main page. I hope to return to it when that notice is gone. > but really if thats what you want to do, I think you are going to suffer a lot in the long run... I have written client/server app's before, the whole point is you want to decide what computation gets performed on which side, not leave it up to the vagaries of lazy evaluation to come up with a random solution. I'll indeed want to keep quite a strict tab on what gets computed where. However, I can foresee the time when I explicitly want a thunk passed around. And I need it now already for making snapshots of the simulation's state, which will most likely contain thunks (e.g. I like to work in infinite game universes, where the data "springs into existence" at the time when it's being looked at; with lazy evaluation, I could express that in a straightforward fashion as an infinite map from coordinates to game data, and without it, I have to use other techniques). Haskell is fun, Haskell is good, but its not the right answer to every question. Just have fun doing whatever you do :) Thanks - I hope it will work out that way. I have seen far too many fun projects turn into bad ones... (might as well have been my own fault, of course - we'll see). If at the end you wrote up a little summary of your project, what you used, how it went, what issues you ran into - then perhaps people can tell you (with the benefit of hindsight) how Haskell might have been. Um... I think you'll be able to tell which problems would have been non-problems in Haskell, but you probably won't be able to tell which non-problems would have been problems in Haskell. (I tend to do things differently than what's the established standard way of doing things. Which means I'm usually both very innovative and very frustrated...) Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Joachim Durchholz wrote: > >> To adhere to uniformity, strong abstraction, and the Principle of >> Least Surprise, we thus chose to force lazy futures in Alice ML. > > Well, I wouldn't have expected that pickling has an effect (other than > wrapping the value up for transfer), so at least I would have been > greatly surprised. That "effect" is just strictness. Since you generally cannot pickle a future (and usually wouldn't want to), pickling naturally has to be strict. Making lazy futures a special case, in this one single strict operation, would be surprising (and extremely ad-hoc). - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
[EMAIL PROTECTED] schrieb: Joachim Durchholz wrote: I'll move on to the alternatives - Alice ML and/or Clean. Both can serialize without forcing lazy subexpressions. I don't know about Clean, but with respect to Alice ML this is not correct: Alice ML uniformly blocks on futures upon pickling, including lazy ones. Bad enough, but not necessarily a showstopper: lazy data structures aren't idiomatic in ML (I just hope they aren't in Alice ML either). Sometimes you may want to pickle lazy suspensions as such, but more often it is not what you want. In particular, the suspension can easily be larger than its result, I'd say that in this case, the suspension should have been forced earlier. I.e. the problem is not in the pickling but in the suspension being larger than its result. I'm entirely unsure how to determine when a suspension should be forced anway. The programmer could give hints, but that would probably break all kinds of abstraction barrier; and the system usually doesn't have enough information to decide when it should do it. Seems like one of those problems that generate lots of PhD papers... and the closure may contain resources which cannot be pickled. If such a suspension was produced by an abstraction you may even argue that making contained resources observable partially breaks the abstraction. Well, Alice ML doesn't serialize things that don't make sense outside the originating process (i.e. resources). That's better than silently serializing a file handle and being surprised by that handle meaning an entirely different file after unpickling. OTOH one could do even better. Simply unpickle a resource as a proxy for the original resource in the originating process. (If the process has died, assume that the resource was closed - the vast majority of resource types has a "closed/unusable" state anyway.) To adhere to uniformity, strong abstraction, and the Principle of Least Surprise, we thus chose to force lazy futures in Alice ML. Well, I wouldn't have expected that pickling has an effect (other than wrapping the value up for transfer), so at least I would have been greatly surprised. I even dislike to see something like that in a language that has side effects. But you can't have everything anyway ;-) Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking advice on a style question
On Sun, 24 Dec 2006 10:39:19 -0500, you wrote: >You might want to look at the following threads discussing how to make >variable-state monad like structures. > >http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/17706 > >http://www.haskell.org/pipermail/haskell/2006-December/018917.html Thanks. I should have realized that Oleg would have had something to say about it. ;) Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking advice on a style question
Hello, Alternatively, I can wrap all of the state up into a single universal structure that holds everything I will ever need at every step, but doing so seems to me to fly in the face of strong typing; at the early stages of processing, the structure will have "holes" in it that don't contain useful values and shouldn't be accessed. You might want to look at the following threads discussing how to make variable-state monad like structures. http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/17706 http://www.haskell.org/pipermail/haskell/2006-December/018917.html -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Hi (There's still no good introduction to Monads, for example. One that's understandable for a programmer who knows his Dijkstra well but no category theory. And a few other things.) I grasped this one first time round: http://haskell.org/haskellwiki/Monads_as_containers No category theory. A basic understanding of apples and boxes is all that is required. http://haskell.org/haskellwiki/Monad has a list of about 10, plus pretty much every book/general tutorial introduces Monad's as well. If there is really nothing out there that helps you understand, you might want to prod some authors as to what isn't clear/understandable. And Haskell let's you serialise thunks just fine (use Yhc), but really if thats what you want to do, I think you are going to suffer a lot in the long run... I have written client/server app's before, the whole point is you want to decide what computation gets performed on which side, not leave it up to the vagaries of lazy evaluation to come up with a random solution. Haskell is fun, Haskell is good, but its not the right answer to every question. Just have fun doing whatever you do :) If at the end you wrote up a little summary of your project, what you used, how it went, what issues you ran into - then perhaps people can tell you (with the benefit of hindsight) how Haskell might have been. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Seeking advice on a style question
In my text/graphics formatting work, I find myself doing a lot of "pipeline" processing, where a data structure will undergo a number of step-by-step transformations from input to output. For example, I have a function that looks like this (the names have been changed to protect the innocent--and to focus on the structure): process :: a -> b -> c -> d -> e process x1 x2 x3 x4 = let y01 = f01 x1 x2 x3; y02 = f02 x1; y03 = f03 y02; y04 = f04 y03; y05 = f05 x1 y01 y04; y06 = f06 x2 y05; (y07,y08) = f07 y01 y06; y09 = f08 y07; (y10,y11) = f09 x2 x4 y09 y08; y12 = f10 y10; y13 = f11 y12; y14 = f12 x1 x2 x3 y01 y13; y15 = f13 y14; y16 = f14 y15 y11 in y16 As you can see, the process is somewhat imperative in overall appearance, with each intermediate function f01..f14 accepting some combination of the original input values and/or intermediate values and returning a new value (or, in some cases, a tuple of values). Obviously, not all of the steps need to be broken out this way. We can, for example, skip the second and third steps and directly write: y04 = f04 $ f03 $ f02 x1; Laying it out this way has a couple of advantages. It makes the steps in the process transparently clear, and if I discover at some point that I need to make a change (e.g., a new requirement causes f13 to need access to x2), it's perfectly obvious where to make the modifications. Nevertheless, it also looks like something that would be amenable to processing with a State monad, except for one thing: The "shape" of the state isn't constant throughout the process. At any given step, new information may be added to the state, and old information may be thrown away, if there is no further need for it. In principle, it could be managed with a bunch of nested StateT monads, but my attempts to do so seem to get so caught up in the bookkeeping that I lose the advantages mentioned above. Alternatively, I can wrap all of the state up into a single universal structure that holds everything I will ever need at every step, but doing so seems to me to fly in the face of strong typing; at the early stages of processing, the structure will have "holes" in it that don't contain useful values and shouldn't be accessed. So here's the question: Is there a reasonable way to express this kind of process (where I suppose that "reasonable" means "in keeping with Haskell-nature") that preserves the advantages mentioned above, but avoids having to explicitly pass all of the various bits of state around? The (unattainable?) ideal would be something that looks like this: process = f14 . f13 . ... . f01 or process = f01 >>= f02 >>= ... >>= f14 Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Joachim Durchholz wrote: > I'll move on to the alternatives - Alice ML and/or Clean. Both can > serialize without forcing lazy subexpressions. I don't know about Clean, but with respect to Alice ML this is not correct: Alice ML uniformly blocks on futures upon pickling, including lazy ones. Sometimes you may want to pickle lazy suspensions as such, but more often it is not what you want. In particular, the suspension can easily be larger than its result, and the closure may contain resources which cannot be pickled. If such a suspension was produced by an abstraction you may even argue that making contained resources observable partially breaks the abstraction. To adhere to uniformity, strong abstraction, and the Principle of Least Surprise, we thus chose to force lazy futures in Alice ML. > No FUD, please ;-) > > And yes I know there are devils lurking in every language and > environment. I'm pretty sure that Haskell has a few others to offer, too. > (There's still no good introduction to Monads, for example. One that's > understandable for a programmer who knows his Dijkstra well but no > category theory. And a few other things.) No FUD, please ;-) ;-) Cheers, - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - not in Haskell though
Tomasz Zielonka schrieb: On Fri, Dec 22, 2006 at 06:16:03PM +0100, Joachim Durchholz wrote: * Forcing the expressions that get written out means that I cannot use lazy evaluation freely. In particular, if some library code returns a data structure that contains a lazy-infinite subexpression, serializing it would not terminate, and I'd have little chance of fixing that. I fear that you may not have a good intuition about laziness and how it is used in practical programming at this moment. Why not try and see if there really is a problem? Because I might end up having sunk several weeks of my time, just to find that there is a problem anyway. Second reason: the restriction will warp my design style. I'll avoid putting infinite data structures in the game data - and that means I can't explore open-end strategies, I'll have to "program around" the issue. For this reason, I'd rather wait until Haskell serializes thunks as a matter of course, and explore lazy programming fully, rather than trying it out now and have my style warped. Now that the first serialization will destroy many of the advantages of laziness, I don't think I should try to wrestle with its disadvantages. A common problem with laziness is the possibility of introducing space leaks. That's when the program accumulates a big thunk which, if forced, would reduce to a small and simple value. "Nobody" is interested in this value now, so it is kept in a lazy, space inefficient form. A classic example is a thunk like this (1+1+1+1+1+1+...) One solution to this problem is "deepSeq" - forcing full evaluation of a data structure. Naive serialisation performs this as a side-effect. What I want to tell is that the "problem" you see here could just as well be a *solution* to a different problem that you haven't considered yet - space leaks! I'm aware of this kind of problem. However, hailing deepSeq as a solution before I even encounter the problem is just constraining the design space. Besides, why use a lazy language at all if I can't use laziness anyway? Most of the data will be in the server, which will get serialized at some time. I'll move on to the alternatives - Alice ML and/or Clean. Both can serialize without forcing lazy subexpressions. I am pretty sure that with those solutions you will meet other problems of the same caliber. No FUD, please ;-) And yes I know there are devils lurking in every language and environment. I'm pretty sure that Haskell has a few others to offer, too. (There's still no good introduction to Monads, for example. One that's understandable for a programmer who knows his Dijkstra well but no category theory. And a few other things.) What I propose is the following: keep Haskell as a possibility (with one discovered problem), consider problems with those other languages, then decide. Exactly. The decision I made right now is just to explore another language. I'll be back and trying out Haskell after a while - though that probably won't before serialization didn't get serious. There doesn't seem to be a perfect programming language. This all said, I still don't think that Haskell or its execution environments are bad. They just don't fit my requirements, which are A) I want to get my feet wet with an FPL (seriously, this time), and B) I want to do a webserver application (I know the domain). Haskell would play well with those requirements. I've created some web applications in it, and I was delighted with the things I learned in the process. I am starting to suspect that you have a third requirement you haven't told us about, like: C) I want to make profit ;-) I won't deny that profit is on the agenda, but it's taking a back seat during the evaluation phase. The situation is slightly different: I'm sick of PHP and want to make profit with something better ;-) However, I admit there are additional requirements, too. I just didn't want to add too much noise explaining why I chose exactly that project for exactly this language. The real hidden agenda is that I'd like to have to option to move away from browser-based stuff, toward client-server stuff. The ability to serialize arbitrary data between applications would be almost indispensable - you can program around the restriction, but then you get impedance mismatches *between Haskell applications*. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
