[Haskell-cafe] parsebinaryoperations
hi I have a function parseInt... which needs an error guard for when the input is not an Int. parseInt :: ParserparseInt [] = []parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)in [(EInt (read digits), removeSpace rest)] Also... I have a function that does this... parseBinaryOp + (5 + 2) if gives...[(Int 5, Int 2, if)] so, op is '+' or . I am unsure of how to begin... parseBinaryOp :: String - String - [(Expr, Expr, String)]parseBinaryOp op str Thankyou Ryan _ Celeb spotting – Play CelebMashup and win cool prizes https://www.celebmashup.com___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ST Monad - what's wrong?
Hi, I'm trying to use the ST monad in order to turn an almost pure function into a pure one: reading a precalculated list of primes into a prime set. But the following code brings an error: primes :: Set Integer primes = runST $ getPrimes primes10h7.txt getPrimes :: String - (forall s. ST s (Set Integer)) getPrimes file = do cont - unsafeIOToST (readFile file) let set = fromList $ map read $ lines cont return set And here is the error: Couldn't match expected type `forall s. ST s a' against inferred type `ST s (Set Integer)' In the second argument of `($)', namely `getPrimes primes10h7.txt' In the expression: runST $ (getPrimes primes10h7.txt) In the definition of `primes': primes = runST $ (getPrimes primes10h7.txt) Compiled with GHC 6.6.1 with extensions activated. Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] AW: ST Monad - what's wrong?
Ok, solved, the use of ($) was the problem. I changed it primes :: Set Integer primes = runST (getPrimes primes10h7.txt) and it compiles (and works too). Nicu -Ursprüngliche Nachricht- Von: Nicu Ionita [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 9. Dezember 2007 12:12 An: 'haskell-cafe@haskell.org' Betreff: ST Monad - what's wrong? Hi, I'm trying to use the ST monad in order to turn an almost pure function into a pure one: reading a precalculated list of primes into a prime set. But the following code brings an error: primes :: Set Integer primes = runST $ getPrimes primes10h7.txt getPrimes :: String - (forall s. ST s (Set Integer)) getPrimes file = do cont - unsafeIOToST (readFile file) let set = fromList $ map read $ lines cont return set And here is the error: Couldn't match expected type `forall s. ST s a' against inferred type `ST s (Set Integer)' In the second argument of `($)', namely `getPrimes primes10h7.txt' In the expression: runST $ (getPrimes primes10h7.txt) In the definition of `primes': primes = runST $ (getPrimes primes10h7.txt) Compiled with GHC 6.6.1 with extensions activated. Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Gtk2hs
Stefan O'Rear wrote: On Sat, Dec 08, 2007 at 08:33:36PM +, Andrew Coppin wrote: I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay! When I ran it, I got this: Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements Er... wow. OK, at this point, I am completely stumped. Any hints? That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class. Well OK, but... how come nobody else has tripped over this before? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST Monad - what's wrong?
The typechecker in 6.6.1 gets confused by the ($) and loses track of the 'freeness' of s (the thread variable) . The same code should work fine in 6.8.1, or alternatively in 6.6.1 without the ($). Cheers pepe On 09/12/2007, at 12:11, Nicu Ionita wrote: Hi, I'm trying to use the ST monad in order to turn an almost pure function into a pure one: reading a precalculated list of primes into a prime set. But the following code brings an error: primes :: Set Integer primes = runST $ getPrimes primes10h7.txt getPrimes :: String - (forall s. ST s (Set Integer)) getPrimes file = do cont - unsafeIOToST (readFile file) let set = fromList $ map read $ lines cont return set And here is the error: Couldn't match expected type `forall s. ST s a' against inferred type `ST s (Set Integer)' In the second argument of `($)', namely `getPrimes primes10h7.txt' In the expression: runST $ (getPrimes primes10h7.txt) In the definition of `primes': primes = runST $ (getPrimes primes10h7.txt) Compiled with GHC 6.6.1 with extensions activated. Nicu ___ 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] ST Monad - what's wrong?
On Dec 9, 2007 2:39 PM, pepe [EMAIL PROTECTED] wrote: The typechecker in 6.6.1 gets confused by the ($) and loses track of the 'freeness' of s (the thread variable) . The same code should work fine in 6.8.1, or alternatively in 6.6.1 without the ($). True. However, note that the release notes of 6.8.1 encourage not to rely in this new feature because it can change in the feature. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST Monad - what's wrong?
True. However, note that the release notes of 6.8.1 encourage not to rely in this new feature because it can change in the feature. I obviously meant in the future, sorry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ARM back end?
On Mon, 03 Dec 2007 18:24:10 +0100, Mathieu Boespflug [EMAIL PROTECTED] wrote: On Nov 2, 2007 10:19 PM, nornagon [EMAIL PROTECTED] wrote: On 03/11/2007, Greg Fitzgerald [EMAIL PROTECTED] wrote: Anybody know of an ARM back end for any of the Haskell compilers? If there's an arm-eabi port somewhere, I might be able to get Haskell code running on the Nintendo DS... https://garage.maemo.org/projects/hugs/ Runs on my Nokia N800 which is arm-eabi based. Mathieu The DS is a bit peckish, but I did get hugs to run on it with devkitPro. I wrote about my experiences at my blog: www.closuretohome.com. Cheers, Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: distinguish functions from non-functions in a class/instances
On 7 Dec 2007, at 12:39 PM, Dan Weston wrote: Luke Palmer wrote: On Dec 7, 2007 7:57 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Dec 7, 2007 7:41 PM, Dan Weston [EMAIL PROTECTED] wrote: Luke Palmer wrote: You can project the compile time numbers into runtime ones: Yes, that works well if I know a priori what the arity of the function is. But I want to be able to have the compiler deduce the arity of the function (e.g. by applying undefined until it is no longer a function), precisely so I don't have to supply it myself. Function arity is (I think) something already known to GHC, so I don't know why we can't get at it too. No, it is not. Consider: compose f g x = f (g x) What is the arity of f? Oh, you're saying at run-time, given an object. No, at compile time. Type is static. What about a type that contains lexical type variables? For that matter, what about a type that ends in a type variable, e.g. head :: [a] - a Is the arity of head (x:xn) = x Different from that of head' :: [a - b] - a - b head' (x:xn) = x ? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] wrote: then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python. This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured. You don't teach *all* of IO to students in one go! This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not. That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is. What is pointless about failure and how to handle it? It's pointless when you're still trying to make your first tweaks to Hello, World! work. -- Dan ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] IVars
(moving to haskell-cafe) readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value? - Conal On Dec 8, 2007 11:12 AM, Marc A. Ziegert [EMAIL PROTECTED] wrote: many many answers, many guesses... let's compare these semantics: readIVar :: IVar a - IO a readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. but the other way: readIVar v = return $ readIVar' v does not work. with this definition, readIVar itself does not block anymore. it's like hGetContents. and... readIVar v = return $! readIVar' v evaluates too much: it wont work if the stored value evaluates to 1) undefined or 2) _|_. it may even cause a 3) deadlock: do writeIVar v (readIVar' w) x-readIVar v writeIVar w cat return x :: IO String readIVar should only return the 'reference'(internal pointer) to the read object without evaluating it. in other words: readIVar should wait to receive but not look into the received box; it may contain a nasty undead werecat of some type. (Schrödinger's Law.) - marc Am Freitag, 7. Dezember 2007 schrieb Paul Johnson: Conal Elliott wrote: Oh. Simple enough. Thanks. Another question: why the IO in readIVar :: IVar a - IO a, instead of just readIVar :: IVar a - a? After all, won't readIVar iv yield the same result (eventually) every time it's called? Because it won't necessarily yield the same result the next time you run it. This is the same reason the stuff in System.Environment returns values in IO. Paul. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST Monad - what's wrong?
On Sun, Dec 09, 2007 at 12:11:42PM +0100, Nicu Ionita wrote: Hi, I'm trying to use the ST monad in order to turn an almost pure function into a pure one: reading a precalculated list of primes into a prime set. But the following code brings an error: primes :: Set Integer primes = runST $ getPrimes primes10h7.txt getPrimes :: String - (forall s. ST s (Set Integer)) getPrimes file = do cont - unsafeIOToST (readFile file) let set = fromList $ map read $ lines cont return set And here is the error: Couldn't match expected type `forall s. ST s a' against inferred type `ST s (Set Integer)' In the second argument of `($)', namely `getPrimes primes10h7.txt' In the expression: runST $ (getPrimes primes10h7.txt) In the definition of `primes': primes = runST $ (getPrimes primes10h7.txt) ST is far too big a hammer to use here. It gives you safety you're not using, at the cost of much more complicated typechecking. I'd just use unsafePerformIO. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal Interactive programmes without using IO? Cool :) I think you misunderstood Lennart. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Another thing is that you should use IO only where it's necessary, which is admittedly rare. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe
Bryan O'Sullivan wrote: Albert Y. C. Lai wrote: I can't blame you for being not observant. Afterall, this is precisely what I'm alluding to with everyone can haz PC [...] Please don't flame people on the list. I'm flaming an idea, not people on the list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ARM back end?
There's an ARM backend in hbc. On Nov 2, 2007 8:30 PM, Greg Fitzgerald [EMAIL PROTECTED] wrote: Anybody know of an ARM back end for any of the Haskell compilers? Thanks, Greg ___ 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] Do real programs need IO? (was IO is a bad example for Monads)
On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Gtk2hs
On Dec 8, 2007 6:33 PM, Andrew Coppin [EMAIL PROTECTED] wrote: (Also, the documentation for Graphics.UI.Gtk.Misc.DrawingArea suggests that you may want to draw a Pixbuf using the pixbufRenderToDrawable function - but GHC complains that this function doesn't exist. I had to use drawPixbuf instead. Wow that has a lot of parameters... In particular, the final two don't seem to be documented. Interesting. They're both 0 in the fastdraw demo.) Just for the record: http://library.gnome.org/devel/gdk/unstable/gdk-Drawing-Primitives.html#gdk-draw-pixbuf I have found that it's eventually useful to try to look at Gtk+ official C documentation when coding with a binding (not only with Gtk2Hs, but also Gtk#, PyGtk, etc). (Also, it seem the second argument should be Maybe GC as the C documentation says it could be a NULL value.) HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] IVars
Thanks, Luke. I'd been unconsciously assuming that the IVar would get written to (if ever) by a thread other than the one doing the reading. (Even then, there could be a deadlock.) - Conal On Dec 9, 2007 9:37 AM, Luke Palmer [EMAIL PROTECTED] wrote: On Dec 9, 2007 5:09 PM, Conal Elliott [EMAIL PROTECTED] wrote: (moving to haskell-cafe) readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value? But I don't think it does. If we're single-threaded, before we writeIVar on it, it returns bottom, but afterward it returns whatever what was written. It's a little fuzzy, but that doesn't seem referentially transparent. Luke - Conal On Dec 8, 2007 11:12 AM, Marc A. Ziegert [EMAIL PROTECTED] wrote: many many answers, many guesses... let's compare these semantics: readIVar :: IVar a - IO a readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. but the other way: readIVar v = return $ readIVar' v does not work. with this definition, readIVar itself does not block anymore. it's like hGetContents. and... readIVar v = return $! readIVar' v evaluates too much: it wont work if the stored value evaluates to 1) undefined or 2) _|_. it may even cause a 3) deadlock: do writeIVar v (readIVar' w) x-readIVar v writeIVar w cat return x :: IO String readIVar should only return the 'reference'(internal pointer) to the read object without evaluating it. in other words: readIVar should wait to receive but not look into the received box; it may contain a nasty undead werecat of some type. (Schrödinger's Law.) - marc Am Freitag, 7. Dezember 2007 schrieb Paul Johnson: Conal Elliott wrote: Oh. Simple enough. Thanks. Another question: why the IO in readIVar :: IVar a - IO a, instead of just readIVar :: IVar a - a? After all, won't readIVar iv yield the same result (eventually) every time it's called? Because it won't necessarily yield the same result the next time you run it. This is the same reason the stuff in System.Environment returns values in IO. Paul. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ 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] IO is a bad example for Monads [was: do]
Conal, It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String-String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper. But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? Sorry, you can't do that in Haskell. or You need to use the IO monad.? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages. It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. -- Lennart On Dec 9, 2007 5:31 PM, Conal Elliott [EMAIL PROTECTED] wrote: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] wrote: then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python. This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured. You don't teach *all* of IO to students in one go! This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not. That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is. What is pointless about failure and how to handle it? It's pointless when you're still trying to make your first tweaks to Hello, World! work. -- Dan ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] IVars
I would claim that it's fine to use the type readIVar :: IVar a - a if you're willing to give the right semantics to newIVar :: IO (IVar a) The semantics is that sometimes when you create an IVar you'll get one that always returns _|_ when read, sometimes you'll get a proper one. Now if you happen to read an IVar and it deadlocks your program, well, sorry, you were unlucky and got a bad IVar that time. So it's possible to explain away the deadlock as something non-deterministic in the IO monad. Doing so comes at a terrible price though, because you can no longer reason about your program. -- Lennart On Dec 9, 2007 7:48 PM, Conal Elliott [EMAIL PROTECTED] wrote: Thanks, Luke. I'd been unconsciously assuming that the IVar would get written to (if ever) by a thread other than the one doing the reading. (Even then, there could be a deadlock.) - Conal On Dec 9, 2007 9:37 AM, Luke Palmer [EMAIL PROTECTED] wrote: On Dec 9, 2007 5:09 PM, Conal Elliott [EMAIL PROTECTED] wrote: (moving to haskell-cafe) readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value? But I don't think it does. If we're single-threaded, before we writeIVar on it, it returns bottom, but afterward it returns whatever what was written. It's a little fuzzy, but that doesn't seem referentially transparent. Luke - Conal On Dec 8, 2007 11:12 AM, Marc A. Ziegert [EMAIL PROTECTED] wrote: many many answers, many guesses... let's compare these semantics: readIVar :: IVar a - IO a readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. but the other way: readIVar v = return $ readIVar' v does not work. with this definition, readIVar itself does not block anymore. it's like hGetContents. and... readIVar v = return $! readIVar' v evaluates too much: it wont work if the stored value evaluates to 1) undefined or 2) _|_. it may even cause a 3) deadlock: do writeIVar v (readIVar' w) x-readIVar v writeIVar w cat return x :: IO String readIVar should only return the 'reference'(internal pointer) to the read object without evaluating it. in other words: readIVar should wait to receive but not look into the received box; it may contain a nasty undead werecat of some type. (Schrödinger's Law.) - marc Am Freitag, 7. Dezember 2007 schrieb Paul Johnson: Conal Elliott wrote: Oh. Simple enough. Thanks. Another question: why the IO in readIVar :: IVar a - IO a, instead of just readIVar :: IVar a - a? After all, won't readIVar iv yield the same result (eventually) every time it's called? Because it won't necessarily yield the same result the next time you run it. This is the same reason the stuff in System.Environmentreturns values in IO. Paul. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
I think your real point is that some things we still haven't figured out how to express functionally. Right? I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal On Dec 9, 2007 12:14 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: [...] IO is important because you can't write any real program without using it. So why not teach enough
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott: I think your real point is that some things we still haven't figured out how to express functionally. Right? That's my point, at least. Currently, AFAIK, the only way to get input and produce output is via the IO monad, so it is de facto necessary for all 'real' programmes, it need not remain so (though I cannot imagine how to functionally express 'readFile Data.txt = print . performAwfullyCoolFunctionalStuff' - surprise me :). Read IO is important as a description of current affairs, not as a claim of the inherent grandeur of it. Cheers, Daniel I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help
hi I have a function parseInt... which needs an error guard for when the input is not an Int. parseInt :: ParserparseInt [] = []parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)in [(EInt (read digits), removeSpace rest)] Also... I have a function that does this... parseBinaryOp + (5 + 2) if gives...[(Int 5, Int 2, if)]so, op is '+' or . I am unsure of how to begin... parseBinaryOp :: String - String - [(Expr, Expr, String)]parseBinaryOp op str Thankyou Ryan _ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Parsing integers [was: Re: [Haskell-cafe] help]
On 12/9/07, Ryan Bloor [EMAIL PROTECTED] wrote: hi I have a function parseInt... which needs an error guard for when the input is not an Int. parseInt :: Parser parseInt [] = [] parseInt xs = let (digits, rest) = span isDigit (removeSpace xs) in [(EInt (read digits), removeSpace rest)] Also... I have a function that does this... parseBinaryOp + (5 + 2) if gives...[(Int 5, Int 2, if)] so, op is '+' or . I am unsure of how to begin... parseBinaryOp :: String - String - [(Expr, Expr, String)] parseBinaryOp op str Check out: http://www.haskell.org/haskellwiki/Homework_help If this isn't homework, try posting again and phrasing your question in the form of a question; saying I am unsure of how to begin doesn't help us help you think about the problem. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt [Teaching children to read] will make America what we want it to be, a literate country and a hopefuller country. -- George W. Bush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Parsing integers [was: Re: [Haskell-cafe] help]
[reply forwarded to list]
-- Forwarded message --
From: Ryan Bloor [EMAIL PROTECTED]
hi
sorry for vagueness.
I am writing a basic Parser from scratch. So far I have functions;
# removeSpaces
# match - which checks if a string is a substring of another
# orParser which combines two parser's abilities
# Basic pasrers like... parseInt, parseTrue, parseFalse, parseBool
using the orParser on True and False.
What I want to do now is have a parseBinaryOp that recognises:
parseBinaryOp + (5 + 2) if gives
[(EInt 5, EInt 2, if)]
So I think that I have to split the initial string into four parts.
+ becomes op
'(' becomes tokenF
')' becomes tokenB
5 becomes e1
2 becomes e2
parseBinaryOp :: String - String - [(Expr, Expr, String)]
parseBinaryOp op str = let (tokenF,e1,op,e2,tokenB) =
I am not sure how to go about separating the string for how I need it
using my other functiuons.
Ryan
Date: Sun, 9 Dec 2007 13:07:23 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Parsing integers [was: Re: [Haskell-cafe] help]
CC: haskell-cafe@haskell.org
On 12/9/07, Ryan Bloor [EMAIL PROTECTED] wrote:
hi
I have a function parseInt... which needs an error guard for when the input
is not an Int.
parseInt :: Parser
parseInt [] = []
parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)
in [(EInt (read digits), removeSpace rest)]
Also... I have a function that does this... parseBinaryOp + (5 + 2) if
gives...[(Int 5, Int 2, if)]
so, op is '+' or . I am unsure of how to begin...
parseBinaryOp :: String - String - [(Expr, Expr, String)]
parseBinaryOp op str
Check out:
http://www.haskell.org/haskellwiki/Homework_help
If this isn't homework, try posting again and phrasing your question
in the form of a question; saying I am unsure of how to begin
doesn't help us help you think about the problem.
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in error, never in doubt
[Teaching children to read] will make America what we want it to be,
a literate country and a hopefuller country. -- George W. Bush
Are you the Quizmaster? Play BrainBattle with a friend now!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] binaryop
hi sorry for vagueness. I am writing a basic Parser from scratch. So far I
have functions; # removeSpaces # match - which checks if a string is a
substring of another # orParser which combines two parser's abilities # Basic
pasrers like... parseInt, parseTrue, parseFalse, parseBoolusing the orParser on
True and False. What I want to do now is have a parseBinaryOp that recognises:
parseBinaryOp + (5 + 2) if gives
[(EInt 5, EInt 2, if)] So I think that I have to split the initial string
into four parts. + becomes op '(' becomes tokenF ')' becomes tokenB 5
becomes e1 2 becomes e2 parseBinaryOp :: String - String - [(Expr, Expr,
String)]parseBinaryOp op str = let (tokenF,e1,op,e2,tokenB) = I am not sure
how to go about separating the string for how I need itusing my other
functiuons. Ryan
_
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Thanks for the clarification. AFAIK, the only way to get input and produce output is via the IO monad Now you know something different, don't you? FRP, Pan, TV. Also Grapefruit, functional forms, and others I'm not thinking of or don't know about. As for your example, mixing the IO with the functional, as you have interferes with composing the result. I can think of two alternatives. One is to move reading printing from the definition to the uses, as with Unix stream filters. Still convenient, and much more flexible. Of course, Unix programs were written in C and so use explicit I/O instead of lazy functional streams. (Though Doug McIlroy, who invented Unix pipes, knew that pipes were equivalent to coroutines and to lazy evaluation. See my modern marriage talk (the video I mentioned) for more about Unix and TV.) A second alternative is to use TV to explicitly capture the interface (I/O), which could look like this: coolTV :: TV (String - String) coolTV = tv (olambda (fileIn Data.txt) defaultOut) performAwfullyCoolFunctionalStuff where tv :: Output src snk a - a - TV src snk a The type parameters src snk are for various interface styles. Then coolTV can then be used on *either* side of a TV-style pipe, resulting in the removal of the reading or writing half. And yes, there are *some* uses of IO for which I'd be hard pressed at this point to offer you an alternative. Which is a far cry from IO being necessary for all real programs, even today. Given this state of affairs, I'd prefer the Haskell community to point newbies away from IO and toward purely functional programming for things like UIs and graphics and help them change their way of thinking. Let's also admit that we haven't yet figured out how to apply our functional paradigm as flexibly or broadly as we'd like, and so meanwhile we have thi monadic IO trick that let's them write nicely factored imperative code that can call into the functional pieces. Regards, - Conal On Dec 9, 2007 12:54 PM, Daniel Fischer [EMAIL PROTECTED] wrote: Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott: I think your real point is that some things we still haven't figured out how to express functionally. Right? That's my point, at least. Currently, AFAIK, the only way to get input and produce output is via the IO monad, so it is de facto necessary for all 'real' programmes, it need not remain so (though I cannot imagine how to functionally express 'readFile Data.txt = print . performAwfullyCoolFunctionalStuff' - surprise me :). Read IO is important as a description of current affairs, not as a claim of the inherent grandeur of it. Cheers, Daniel I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] IVars
Hi Conal, On Dec 9, 2007 6:09 PM, Conal Elliott [EMAIL PROTECTED] wrote: readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value? From the rest of Marc's post, I understood the point to be that readIVar lets you do something that readIVar' does not let you do: block until the IVar is written, then continue *without* first evaluating the thunk in the IVar to WHNF. I haven't used IVars myself, so this isn't informed by hands-on experience, but it does sound sensible to me that block until the IVar has been written and evaluate the thunk to WHNF should be separable. All the best, - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
Thanks. If I'm tracking, your real point is that imperative programming in Haskell is still useful enough to keep around. I agree. I'm still puzzled. Did you understand something I said, or maybe someone else said, as suggesting that imperative programming be removed from Haskell any time soon? It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. How can we possibly teach them to stay away from IO where possible if we're also telling them that they can't write *any* real program without using IO? Cheers, - Conal On Dec 9, 2007 12:02 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String-String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper. But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? Sorry, you can't do that in Haskell. or You need to use the IO monad.? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages. It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. -- Lennart On Dec 9, 2007 5:31 PM, Conal Elliott [EMAIL PROTECTED] wrote: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] wrote: then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python. This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured. You don't teach *all* of IO to students in one go! This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not. That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is. What is pointless about failure and how to handle it? It's pointless when you're still trying to make your first tweaks to Hello, World! work. -- Dan ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Daniel Fischer [EMAIL PROTECTED] writes: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Well, I guess you could get pretty far using 'interact' - far enough in an educational setting to do lists and Maybe, and then monads, before introducing monadic IO. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Sonntag, 9. Dezember 2007 23:35 schrieb Ketil Malde: Daniel Fischer [EMAIL PROTECTED] writes: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Emphasis on *use*, introduce the concept of monads not before lists, Maybe and Either. Well, I guess you could get pretty far using 'interact' - far enough in an educational setting to do lists and Maybe, and then monads, before introducing monadic IO. -k Pretty far, yes, and in an educational setting, at a university, it is quite common, I believe, to use an interpreter for a while, not producing executables (that's how I met Haskell, write pure functions and type expressions at the Hugs prompt). But what about a tutorial for programmers? How would you do main = do putStrLn Please enter your name. name - getLine putStrLn $ Hello ++ name ++ , nice to meet you. in that setting? I doubt you could keep many interested without telling them how to create standalone programmes, including reading input from stdin and printing output to stdout. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsebinaryoperations
Maybe you should look into Parsec, a Haskell library for writing parsers. Google should find what you need. - Phil On Dec 9, 2007 1:58 AM, Ryan Bloor [EMAIL PROTECTED] wrote: hi I have a function parseInt... which needs an error guard for when the input is not an Int. parseInt :: Parser parseInt [] = [] parseInt xs = let (digits, rest) = span isDigit (removeSpace xs) in [(EInt (read digits), removeSpace rest)] Also... I have a function that does this... parseBinaryOp + (5 + 2) if gives...[(Int 5, Int 2, if)] so, op is '+' or . I am unsure of how to begin... parseBinaryOp :: String - String - [(Expr, Expr, String)] parseBinaryOp op str Thankyou Ryan -- Get closer to the jungle… I'm a Celebrity Get Me Out Of Here!http://entertainment.uk.msn.com/tv/realitytv/im-a-celebrity/ ___ 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] Point and link
Andrew Coppin wrote: Such a GUI would be cool for a number of projects. It still needs to exist first. ;-) I don't think anyone has mentioned this: http://haskell.org/Blobs which I haven't used, though the screenshots look good. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
I doubt all imperative programming will be banished from Haskell anytime soon. I really, really wish we had all the nice abstractions in place already, but we just don't. You can't write any program in Haskell without using IO, because the type of main involves IO. And currently I believe that almost any real program will have to involve IO. (BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell because I insisted on it.) It's just from my experience. No matter how pure your program is, here and there it will be interacting with the rest of the world. -- Lennart On Dec 9, 2007 10:16 PM, Conal Elliott [EMAIL PROTECTED] wrote: Thanks. If I'm tracking, your real point is that imperative programming in Haskell is still useful enough to keep around. I agree. I'm still puzzled. Did you understand something I said, or maybe someone else said, as suggesting that imperative programming be removed from Haskell any time soon? It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. How can we possibly teach them to stay away from IO where possible if we're also telling them that they can't write *any* real program without using IO? Cheers, - Conal On Dec 9, 2007 12:02 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String-String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper. But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? Sorry, you can't do that in Haskell. or You need to use the IO monad.? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages. It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. -- Lennart On Dec 9, 2007 5:31 PM, Conal Elliott [EMAIL PROTECTED] wrote: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] wrote: then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python. This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured. You don't teach *all* of IO to students in one go! This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not. That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is. What is pointless about failure and how to handle it?
Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)
Maybe I'm exaggerating, but it's true for 96% of all programs. (96% is with a :-)) I did not express anything that was meant to be a perpetual truth, only best practice at the moment. For a living I write programs that are almost without interaction with the outside world. Still, I need a to spend 1% of the code doing IO related stuff and it's very important that I can do it. The other 99% are just pure computations. But that I think that validates rather than invalidates my point. -- Lennart On Dec 9, 2007 8:29 PM, Conal Elliott [EMAIL PROTECTED] wrote: I think your real point is that some things we still haven't figured out how to express functionally. Right? I would certainly agree with that part. Perhaps you exaggerating when you wrote IO is important because you can't write any real program without using it. Cheers, - Conal On Dec 9, 2007 12:14 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad. -- Lennart On Dec 9, 2007 7:26 PM, Conal Elliott [EMAIL PROTECTED] wrote: On Dec 9, 2007 10:07 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Interactive programmes without using IO? Cool :) And how! I think you misunderstood Lennart. Thanks for checking. In this case, I think I understood Lennart fine and that he was saying what you're saying. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === If by programme, you mean the code I write, then I'm happy to deny that my programme has to do these things. Examples below. If you include a stateful RTS, then no I don't deny it. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Explicit imperative programming is just one way to deal with input output, not the only way. As proof, see FRP, Pan, or TV programs, which contain uses of none of these functions. (Nor could they, as these libraries are functional, having IO-free types and semantics.) Moreover, use of imperative programming sacrifices some of the semantic simplicity composability that makes FP so appealing. That's why I'd like to see this belief in its necessity dispelled. That said, I don't think the existing functional (non-IO) approaches to interaction are quite there yet with the flexibility of imperative programming. It will take more work to get them there, and that work is mostly likely to be pursued by people who doubt the necessity of IO for writing real programs. In that sense, Lennart's and your statements are self-fulfilling prophechies, as are mine. BTW, if you haven't seen it already, please check out http://haskell.org/haskellwiki/TV . The TV (tangible values) approach includes a simple algebra of interfaces (input/output) and keeps separable from the core computation. The separability allows the interface parts to be composed in parallel with the core part. For instance, when two function-valued TVs are composed, the interfaces are peeled off, so that the core functions can be composed directly. The output half of one interface and the matching input half of the other are discarded. The remaining input and output halves are recombined into a new interface, which is used as the interface of the composed TV. The core interface algebra can be used for text stream i/o, GUIs, and many other possible styles of information passing. I mention TV, because it's an example of combining the purity composability I love about FP with the usability a real app. For more about this combination, please see my Google tech talk Tangible Functional Programming: a modern marriage of usability and composability ( http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html). That talk focus on end-user composability, but the essential points apply as well to explicit programming. As I mentioned before, TV (a) is currently less flexible than imperative/IO programming, and (b) has the composability, guaranteed safety, and amenability to reasoning of pure functional programming. Cheers, - Conal Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott: IO is important because you can't write any real program without
Re: [Haskell-cafe] Problem with Gtk2hs
On Sat, 2007-12-08 at 13:08 -0800, Stefan O'Rear wrote: On Sat, Dec 08, 2007 at 08:33:36PM +, Andrew Coppin wrote: I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay! When I ran it, I got this: Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements Er... wow. OK, at this point, I am completely stumped. Any hints? That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class. The MArray class changed in ghc-6.8 and we didn't notice until the gtk2hs release was already out. So there are a couple workarounds, either grab the darcs version of the 0.9.12 branch which contains the fix: http://darcs.haskell.org/gtk2hs-branches/gtk2hs-0.9.12/ Or use the released version with ghc-6.6.x rather than 6.8.x, since 6.6 has the previous different MArray interface. Or use the unsafe indexing operators which bypass the bounds check which calls getNumElements. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: xmonad 0.5: a tiling window manager
The xmonad dev team is pleased to announce the 0.5 release of xmonad! http://xmonad.org xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating windows * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Easy, powerful customisation and reconfiguration in Haskell * Large extension library * Extensive documentation and support for hacking Get it! More information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.5 release, and its dependencies, are available from hackage.haskell.org, here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad **The headlines** xmonad 0.5 is a major new release of xmonad, allowing, for the first time, dynamic extension in Haskell without requiring recompilation. Extension and configuration of xmonad is now faster, simpler, and more flexible. All configuration is done via the ~/.xmonad/xmonad.hs file. Example config files and screenshots are available on the wiki: http://haskell.org/haskellwiki/Xmonad/Config_archive This marks the final break from its dwm origins. As a result, xmonad is now also much easier to package, distribute and extend, as recompilation of xmonad is not required to extend it. New features: * xmonad is now a library, as is the collection of xmonad extensions * xmonad is configured by editing ~/.xmonad/xmonad.hs * simpler layout hooks type and interface * small EDSL for writing window management rules * support for ghc 6.8.x * xmonad now requires Cabal 1.2 or newer * small bug fixes Extensions: xmonad comes with a huge library of extensions (now more than 5 times the size of xmonad), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. Examples include: * ion-like window tabs * status bar support * X property and hints support * altnerative layout algorithms For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Brought to you by the xmonad team: Spencer Janssen Don Stewart Jason Creighton Andrea Rossato David Roundy Brent Yorgey with code contributions from: Brandon AllberyChris Mears Shachaf Ben-Kiki Eric Mertens Alec Berryman Neil Mitchell Gwern Branwen Devin Mullins Joachim Breitner Daniel Neri Alexandre Buisse Stefan O'Rear Nick Burlett Simon Peyton Jones Peter De Wachter Hans Philipp Annen Aaron Denney Karsten Schoelzel Nelson Elhage Michael Sloan Shae Erisson Ivan Tarasov Joachim FastingAlex Tarkovsky Michael Fellinger Christian Thiemann David Glasser Joe Thornber Kai GrossjohannMatsuyama Tomohiro Dave Harrison Daniel Wagner Juraj Hercek Ferenc Wagner Sam Hughes Jamie Webb Miikka KoskinenKlaus Weidner David Lazarnornagon Lucas Mai timthelion Robert Marlow Valery V. Vorotyntsev Dougal Stanton Joel Suovaniemi Mats Jansborg Dmitry Kurochkin Clemens Fruhwirth As well as the support of many others on the #xmonad and #haskell IRC channels, and the wider Haskell and window manager communities. Thanks to everyone for their support! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
It so happens that Haskell currently insists on main :: IO (). That's simple to fix, however, and with great pay-off. Suppose instead main :: TV a (where I'm omitting the other TV type args for simplicity.) Then a program could not only be run, but also composed with other programs. They could even be composed by the end-user *while running*, as in Eros. Similarly, ghci implicitly inserts print when given a non-IO type. We could make that mechanism a little more general, and allow implicit insertions of other kinds of renderers, for purely functional images, music, 2D 3D geometry animation, interactive GUIs, etc. - Conal On Dec 9, 2007 4:38 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: I doubt all imperative programming will be banished from Haskell anytime soon. I really, really wish we had all the nice abstractions in place already, but we just don't. You can't write any program in Haskell without using IO, because the type of main involves IO. And currently I believe that almost any real program will have to involve IO. (BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell because I insisted on it.) It's just from my experience. No matter how pure your program is, here and there it will be interacting with the rest of the world. -- Lennart On Dec 9, 2007 10:16 PM, Conal Elliott [EMAIL PROTECTED] wrote: Thanks. If I'm tracking, your real point is that imperative programming in Haskell is still useful enough to keep around. I agree. I'm still puzzled. Did you understand something I said, or maybe someone else said, as suggesting that imperative programming be removed from Haskell any time soon? It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. How can we possibly teach them to stay away from IO where possible if we're also telling them that they can't write *any* real program without using IO? Cheers, - Conal On Dec 9, 2007 12:02 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Conal, It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String-String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper. But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? Sorry, you can't do that in Haskell. or You need to use the IO monad.? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages. It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. -- Lennart On Dec 9, 2007 5:31 PM, Conal Elliott [EMAIL PROTECTED] wrote: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful simpler reasoning, safety and composability. - Conal On Dec 8, 2007 1:26 AM, Lennart Augustsson [EMAIL PROTECTED] wrote: I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] wrote: then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate
Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe
Hi, Yes, I looked into it as per the Mailman documentation. I was wondering if there was a module already that could do it, to avoid some work :) What is the difference between In-Reply-To and References? And the list of posts was just the beginning. Each post would have sufficient information to reconstruct the tree... And looks like this post has gone on a tangent :D Vimal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe
And looks like this post has gone on a tangent :D Vimal And looks like this _thread_ has gone on a tangent :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] IVars
Thanks. I don't know for what uses of IVars the difference in expressiveness is helpful, but now I get that the difference is there. Cheers, - Conal On Dec 9, 2007 2:08 PM, Benja Fallenstein [EMAIL PROTECTED] wrote: Hi Conal, On Dec 9, 2007 6:09 PM, Conal Elliott [EMAIL PROTECTED] wrote: readIVar' :: IVar a - a readIVar' = unsafePerformIO . readIVar so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as unsafeReadIVar or unsafeReadMVar. The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value? From the rest of Marc's post, I understood the point to be that readIVar lets you do something that readIVar' does not let you do: block until the IVar is written, then continue *without* first evaluating the thunk in the IVar to WHNF. I haven't used IVars myself, so this isn't informed by hands-on experience, but it does sound sensible to me that block until the IVar has been written and evaluate the thunk to WHNF should be separable. All the best, - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need help please.
hi I am writing a basic Parser from scratch. So far I have functions;#
removeSpaces# match - which checks if a string is a substring of another#
orParser which combines two parser's abilities# Basic pasrers like... parseInt,
parseTrue, parseFalse, parseBoolusing the orParser on True and False.What I
want to do now is have a parseBinaryOp that recognises:parseBinaryOp + (5 +
2) if gives [(EInt 5, EInt 2, if)]So I
think that I have to split the initial string into four parts.+ becomes op'('
becomes tokenF')' becomes tokenB5 becomes e12 becomes e2parseBinaryOp ::
String - String - [(Expr, Expr, String)]parseBinaryOp op str = let
(tokenF,e1,op,e2,tokenB) =I am not sure how to go about separating the string
for how I need itusing my other functiuons. Ryan
_
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do real programs need IO? (was IO is a bad example for Monads)
(...) Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... === As long as we use current interfaces, no one would deny it. But after reading some stuff about Epigram language, I wonder if those ideas could not be used to write a better interface to computers. Then, all those tasks would be handled by your interface plug-ins, not by programs. Really, we need to do all of that today. But I believe reading from keyboard, files etc. should not be part of programs we write daily, just a task for a basic interface to which our programs should be linked. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
Argh, that last sentence should read the file is left alone.. On Dec 9, 2007 10:15 PM, David Fox [EMAIL PROTECTED] wrote: Here is a practical example I ran into a few days ago. With this expression: writeFile path (compute text) the file at path would be overwritten with an empty file if an error occurs while evaluating (compute text). With this one: writeFile path $! (compute text) the file alone when an error occurs. On Nov 17, 2007 8:04 PM, PR Stanley [EMAIL PROTECTED] wrote: Hi okay, so $! is a bit like $ i.e. the equivalent of putting parentheses around the righthand expression. I'm still not sure of the difference between $ and $!. Maybe it's because I don't understand the meaning of strict application. While we're on the subject, what's meant by Haskell being a non-strict language? Cheers Paul At 01:50 15/11/2007, you wrote: On 14 Nov 2007, at 4:32 PM, Shachaf Ben-Kiki wrote: On Nov 14, 2007 4:27 PM, Justin Bailey [EMAIL PROTECTED] wrote: It's: f $! x = x `seq` f x That is, the argument to the right of $! is forced to evaluate, and then that value is passed to the function on the left. The function itself is not strictly evaluated (i.e., f x) I don't believe. Unless you mean f -- which I still don't think would do much -- it wouldn't make sense to evaluate (f x) strictly. Right. (f x) evaluates f and then applies it to x. (f $! x) evaluates x, evaluates f, and then applies f to x. jcc ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
