- Haskell-Cafe - Haskell.org

Fwd: Re: Yet Another Monad Tutorial
by blaat blaat 13 Aug '03

13 Aug '03

>From: Derek Elkins <ddarius(a)hotpop.com> >"blaat blaat" <l4t3r(a)hotmail.com> wrote: [...] > > However, given that observation, the fact that IO is a monad I find to > > be a _rather arbitrary design decision_; why not define a small term > > language which may be passed to the OS? > >That would be confusing to use or restrictive (unless done exceedingly >well perhaps), it would be awkward to define, and it would pretty much >require arbitrary design decisions (what should be included in this >language? what are it's semantics? etc). > > Why not have (some limited) > > introspection on programs which we build? > >It would be round-about in both implementation and use to do this. >Nevertheless, you can easily view the IO monad as an imperative language >-embedded- in Haskell. Even when writing mostly imperative code >Haskell gives you much more flexibility and protection than many >imperative languages, especially the more popular ones. > >[...] > > > Are we missing out on usefull stuff? > >No, but if we were, it'd be trivial to test/get it with an appropriate >top-level runTheProgram IO computation definable in Haskell today. Trivial to test I fully agree with; however, to the missing out on usefull stuff I am not convinced. Please allow me to continue my trolling. To use the IO monad for impure calculations is, of course, a design decision. It is arbitrary to the point that I have the freedom not to agree with it; but hey, even I know the thing works ;-). The key point to my email was that doing impure IO possibly has little to do with a monadic style of programming but with the fact that we can functionally construct a description of an impure program which is evaluated _only_ when delivered as a sole result of a Haskell computation. I find that somewhat odd; but not to the point I cannot live with it ;-) About the indirectness issue. The benefit of choosing a monad is clear - the evaluation/rewrite of an action corresponds directly with an impure subroutine call. Moreover, the action can be discarded and, as you pointed out, the description of these impure subroutine calls are trivially embedded directly into Haskell - giving typesafety as a reward. It is both effective and efficient. Great.... Hail to the monad! Hmmm, uhm, but let's think further... What did we lose? Well, introspection comes to mind. A monad is strange in the sense that, actually, there does not seem to be any reason to compute its value since we cannot possibly get anything out of it. In case of IO, only the haskell interpreter can. And, introspection is a nice thing to have, especially for compiler writers. Although I think the benefits in Haskell would be limited, an application might be that I could write my own promotion functions on my own programs. Think of the following though experiment. What if I would have a function "unparse:IO a->String" which gives the textual representation of the specification of the object of type IO a? Clearly, IO is not a monad anymore. Moreover, I don't think it would break the purity of Haskell. And surely, in case of the IO monad, we can think of better manners to break a program down. Hmm, I am rambling. The point is, I think there is no reason to discard all alternatives to monads; I believe that central in the IO-issue is not the fact that we are using monads for IO - but that we can purely create impure programs which do the IO for us ;-), and that those do not have to be of the monadic kind (with all respect to the baffling ingenuity of the invention). Cheers, l4t3r _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Re: Yet Another Monad Tutorial
by Derek Elkins 13 Aug '03

13 Aug '03

On Wed, 13 Aug 2003 13:26:34 +0200 "blaat blaat" <l4t3r(a)hotmail.com> wrote: I have a long reply, perhaps I'll post it later. Here's a more pragmatic short one. > What did we lose? Well, introspection comes to mind. A monad is > strange in the sense that, actually, there does not seem to be any > reason to compute its value since we cannot possibly get anything out > of it. In case of IO, only the haskell interpreter can. And, > introspection is a nice thing to have, especially for compiler > writers. Although I think the benefits in Haskell would be limited, an > application might be that I could write my own promotion functions on > my own programs. Lot's of issues with this paragraph, but here are the questions. What do you mean by "promotion function"? How would you write it in your hypothetical Haskell? How is it related to IO? How do monads and/or the IO monad in particular cause problems? Why couldn't the same be done using monads or why would it be significantly harder if it can be done? > Think of the following though experiment. What if I would have a > function "unparse:IO a->String" which gives the textual representation > of the specification of the object of type IO a? Clearly, IO is not a > monad anymore. Moreover, I don't think it would break the purity of > Haskell. And surely, in case of the IO monad, we can think of better > manners to break a program down. Keith has already pointed out the flagrant error here; which I also point out in my long reply. But again, the questions... What is unparse supposed to return? What does it have to do with IO in particular, i.e. why do I want to unparse IO computations especially? Why can't it be done with (or over) the current IO monad? What other ways do you want to breakdown a program, still resulting in understandable behavior, but can't because of the IO monad? > Hmm, I am rambling. The point is, I think there is no reason to > discard all alternatives to monads; > I believe that central in the > IO-issue is not the fact that we are using monads for IO - but that we > can purely create impure programs which do the IO for us ;-), and that > those do not have to be of the monadic kind. I have comments for these too, but I'll keep this short. Basically, I don't really see how what you want has all that much to do with IO in general, and I don't see monads get in the way.

1 0

[String]->[[Bool]]
by Tn X-10n 13 Aug '03

13 Aug '03

2 1

[String]->[[Bool]] 2
by Tn X-10n 13 Aug '03

13 Aug '03

2 1

Yet Another Monad Tutorial
by blaat blaat 13 Aug '03

13 Aug '03

Hmmm, I personally always thought of the IO monad as being a synonym for "Program" (or, for functions wich return an IO a, "a subroutine with side-effects which returns a value of type a"). We can build mini programs (like putStr), and compose them in a sequential manner (including something alike assignment). I personally use the following analogy. Someone, somewhere, sometime must have thought, "Great, if I cannot do imperative programming directly, I can damned well create imperative programs and have _them_ evaluated, grumbl!" And with that thought, he solved numerous problems ;-) Can we really make cheese out of it? (Dutch saying) For what is the interpretation of an object of type IO a? Well, it is a bit of a hack atop of Haskell, isn't it? If we return a complex type with an IO a object in it, the object cannot be evaluated, but if we return a IO object solely (program), the program get evaluated (passed to the (Haskell)-OS). However, given that observation, the fact that IO is a monad I find to be a _rather arbitrary design decision_; why not define a small term language which may be passed to the OS? Why not have (some limited) introspection on programs which we build? Purity will never be broken since the only way to get a "program" evaluated is to pass it to the Haskell-OS. Are we missing out on usefull stuff? Hehe... God, we might as well just generate impure graph rewrite rules,.... or plain C for that matter ;-). Cheers, l4t3r ps: Mind you, nothing wrong with that IO monad. It works, why break it. ;-) _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

[String] -> [[Bool]]
by Tn X-10n 13 Aug '03

13 Aug '03

3 2

AW: Yet Another Monad Tutorial
by Markus.Schnell＠infineon.com 13 Aug '03

13 Aug '03

> The overall message I have taken from your post is that I need to > be more precise to convey the correct information and avoid confusion > (or worse, misinformation). As I understood it, the tutorial should be instructive. So I would not try to be more precise at the beginning, because too much detail would lead to confusion for a beginner. Start with something like "I'm now telling you some lies, which make it easier to grasp the idea of the monad, but further down the road, I'll reexplain some concepts and be more precise there." This was done by Don Knuth for the Typesetting-Books and it worked very well (for me). I hope this is a sensible idea. Markus -- Markus Schnell Infineon Technologies AG, CPR ET Tel +49 (89) 234-20875

1 0

Database interface
by Thomas L. Bevan 13 Aug '03

13 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone know if there is work being done on a standard Haskell database interface. I was very impressed with HaskellDB but I understand that it uses Haskell extensions not present in GHC. Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/OhsFYha8TWXIQwoRAhkUAKDE/z2fepe7565J5+9JmMGZxpmQvwCgre/R JokIUilP8aF37d764FYFZbY= =Zlx6 -----END PGP SIGNATURE-----

2 3

Help with Exceptions on I/O
by Alexandre Weffort Thenorio 12 Aug '03

12 Aug '03

I have a program which creates textfiles out of other files. Since the program is runned from windows I output some text strings (Like "File created succefully") and I need to stop the program before it quits so that the user can read the line outputted to know what went on and then he can press ENTER to quit the program. I managed to do this fine if no error occurs but when a error occurs I am having problems. The code goes like that main :: IO() main =catch (do Do all the needed stuff here putStr "File created Successfully. Press RETURN to quit" dummy <- getLine --Halts the program so the user can read the above line) putStr "Exiting now..." --needed since I can't finish a do function with the "dummy<- getLine" line) (\_ -> do putStr "\nFile not found. Press RETURN (ENTER) to quit." dumb <- getLine putStr "\nExiting...") So when the program runs, if the input file is found the program writes successfull creation of file but if the file doesn't exist, after the user gives the input filename and press enter, the program creates a new line and Halts (Probably because of the getLine function) without writing out anything, then when the user press ENTER again it writes the line at the first putStr (File not...), then writes the next putStr line under it (Exiting...) and exits. I don't know why it doesn't wirte the first line, halts and then when user press enter it writes the second and quits. Can anybody help me as I am not very familiar with exception and catches. Another question I have is: Is there any other function rather than getLine that halts a program and continues when a user press any key (Instead of ENTER) and besides this is an ugly code since getLine wasn't made for that but I couldn't find anything else myself. Thank you in advance. Best Regards Alex

1 0

RE: .. Drowning in stateful, side-effect riddled, spaghetti code? We have the answer. fdps[]c.
by Bayley, Alistair 12 Aug '03

12 Aug '03

Hey there! Stateful side-effect-laden spaghetti programming sucks, and so does the cost.. feel like your [sic] getting ripped off? ... We tear up your code and give you and your colleagues a fresh start .. - Save you a lot of money by eliminating side-effects - Develop new code in substantially reduced time - Stop customers/managers calling you on the phone about late delivery - Avoid code maintenance debt ... and more! Why keep dealing with the stress, and headaches, of mainstream programming styles? Combine pure and lazy functional programming and get on with your life today!! Come here and take a look at how we can help. http:///www.haskell.org > -----Original Message----- > From: koxwhdsinsad(a)msn.com [mailto:koxwhdsinsad@msn.com] > Sent: 12 August 2003 08:47 > To: haskell-cafe(a)haskell.org > Subject: .. Drowning in debt? We have the answer. fdps[]c. > > > Hey There! > > Debt sucks, and so do the repayments.. feel like your getting > ripped off? .. > We tear up your debt and give you and your family a fresh start .. > > - Save you a lot of money by eliminating late fees > - Settle your accounts for a substantially reduced amount > - Stop creditors calling you on the phone > - Avoid bankruptcy > > ... and more! > > Why keep dealing with the stress, and headaches? > > Combine your debt into a low interest repayment and > get on with your life today!! > > Come here and take a look at how we can help. > > http://tops@www.slashmonthlypayments.com/index.php?N=g ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

2 1