Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On Thu, Dec 29, 2011 at 3:45 AM, Antoine Latter aslat...@gmail.com wrote: On Wed, Dec 28, 2011 at 3:52 PM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I just received a bug report from a client that, when an input file is open in FrameMaker, my program gives a permission denied error. This bug is reproducible with a simple Haskell program: import System.IO main = do putStrLn here1 h - openFile filename.txt ReadMode putStrLn here2 I tried writing a simple C program using fopen, and it ran just fine. Does anyone have experience with this issue, and know of a workaround? When GHC opens files for reading, it asks windows to disallow write access to the file. I'm guessing that Framemaker has the file open for writing, so GHC can't get that permission. I imagine that the Haskell runtime does this to make lazy-io less crazy. Here's the call GHC makes: https://github.com/ghc/packages-base/blob/0e1a02b96cfd03b8488e3ff4ce232466d6d5ca77/include/HsBase.h#L580 To open a file for reading in your C demo in a similar way you could do something like: fd = _sopen(file_name, _O_RDONLY | _O_NOINHERIT,_SH_DENYWR, 0); Here _SH_DENYWR is telling windows to deny others from writing to this file. Here's the msdn link for _sopen and _wsopen: http://msdn.microsoft.com/en-us/library/w7sa2b22%28VS.80%29.aspx I haven't tested any of that, but that should help you in reproducing how GHC opens files for read on windows. You should be able to use System.Win32.File.createFile with a share mode of (fILE_SHARE_READ .|. fILE_SHARE_WRITE) and then wrangling a Haskell Handle out of that, but I haven't tried it. Or you could modify the call to _wsopen and FFI call that - it takes fewer parameters and might be less confusing. Antoine Thanks for the advice Antoine, it was spot on. I modified my uri-conduit package with the following commit: https://github.com/snoyberg/xml/commit/a4763739093c525d8f509b11e72a2d17894afaac Since conduits re-implement buffering themselves, I don't think there's any advantage to wrapping up the FD in a Handle again, except perhaps for better integration with the async calls of the multi-threaded runtime. But since I'm not using that for my Windows code, and I don't think the multi-threaded runtime supports Windows particularly well in the first place, this seems like an acceptable trade-off. Does anyone see any issues with the code? Would it be useful for me to expose this code elsewhere, such as in conduit itself? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Steve Horne wrote: Heinrich Apfelmus wrote: Purity has nothing to do with the question of whether you can express IO in Haskell or not. The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: Yes - AT COMPILE TIME by the principle of referential transparency it always returns the same action. However, the whole point of that action is that it might potentially be executed (with potentially side-effecting results) at run-time. Pure at compile-time, impure at run-time. What is only modeled at compile-time is realized at run-time, side-effects included. Well, it's a matter of terminology: impure /= has side effects. The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Sorry, a long and pseudo-philosophical treatise. Trash it before reading. Heinrich Apfelmus: You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. I have no reason to be categorical, but I believe that calling the interaction of a Haskell programme with the World - a side effect is sinful, and it is a source of semantical trouble. People do it, SPJ (cited by S. Horne) did it as well, and this is too bad. People, when you eat a sandwich: are you doing side effects?? If you break a tooth on it, this IS a side effect, but neither the eating nor digesting it, seems to be one. This term should be used in a way compatible with its original meaning, that something happens implicitly, behind the curtain, specified most often in an informal way (not always deserving to be called operational). If you call all the assignments side effects, why not call - let x = whatever in Something - also a local side-effect? Oh, that you can often transform let in the application of lambda, thus purely functional? Doesn't matter, Steve Horne will explain you that (sorry for the irony): let is a compile-time pure construct ; at execution this is impure, because x got a value. S.H. admits that he reasons within his model, and has problems with others. Everybody has such problems, but I see here something the (true) Frenchies call un dialogue de sourds. For me a Haskell programme is ABSOLUTELY pure, including the IO. The issue is that `bind` within the IO monad has an implicit parameter, the World. In fact, a stream of Worlds, every putWhatever, getLine, etc. passes to a new instance. We do not control this World, we call it imperative (whatever this means, concerning eating a sandwich, or exploding an impure neutron bomb), so we abuse the term side effect as hell! The Haskell sector of the global world, the programme itself is just a function. Pure as the robe of an angel. Simply, you are not allowed by the Holy Scripts to look under this robe. == The rest is a (pure of course) délire. Well, you might not believe me, but philosophically you don't need to imagine the World as imperative. Personally I am a believer in the Quantum Religion. If you accept all them Holy Dogmas of Unitarity, of Linearity, etc., if you believe in the True Quantum Nature of the real world, - then it becomes ... functional. Pure. Without a single trace of any side effects. The problem is that residing inside this world precludes the possibility of considering *observed things* as pure, they are conceptually detached from the stream of the Universe Vectors. They change, so you say: HaHa!! A particle got ASSIGNED a new position! This is an imperative side-effect! - - while from the point of view of an external observer, a common evolution operator transformed both of you, YOU and the particle into a new instance of this sector. OK, I stop here, otherwise the digestion of your sandwiches may produce some side effects. Jerzy Karczmarczuk Caen, France. (William the Conqueror was here. Produced one nice side-effect.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 08:48, Heinrich Apfelmus wrote: Steve Horne wrote: Heinrich Apfelmus wrote: Purity has nothing to do with the question of whether you can express IO in Haskell or not. The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: Yes - AT COMPILE TIME by the principle of referential transparency it always returns the same action. However, the whole point of that action is that it might potentially be executed (with potentially side-effecting results) at run-time. Pure at compile-time, impure at run-time. What is only modeled at compile-time is realized at run-time, side-effects included. Well, it's a matter of terminology: impure /= has side effects. The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. WRT the IO monad, has side effects is shorthand for potentially has side effects, and potentially is sensitive to side-effects. Both are equally true - as soon as you opt to allow side-effects you also opt to allow sensitivity to side-effects, at least as far as the type system is concerned. For example an IORef - you can mutate the variable it references, and whenever you dereference it the result depends on whatever past mutations have occurred while the program was running. In a way, it's a shame - it might be interesting to separate causing and reacting to side-effects in the type system (while allowing both to be sequenced relative to each other of course - having I action and O action both subtypes of IO action perhaps). It could be a useful distinction to make in some cases in a preventing-classes-of-bugs-through-typechecking kind of way. The const keyword in C++ might be a relevant analogy - disallowing locally-caused mutation of an IORef while allowing sensitivity to mutations caused elsewhere. Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. Again, this is nothing new - it's clear from SPJs Tackling the Awkward Squad that this is what the IO monad is meant for, and if it's evil then at least it's controlled evil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Dec 29, 2011, at 9:16 AM, Donn Cave wrote: Quoth Gregg Reynolds d...@mobileink.com, On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Ok, let's parse it out. …it's not the int you would get 'when executing this action. Close, but no cooky: it's not any kind of int at all (try doing arithmetic with it). IO Int is a piece of rhetoric for the mental convenience of the user; Haskell does not and cannot know what the result of an IO action is, because it's outside the scope of the language (and computation). (The Int part of IO Int refers to the input, not the output; it's just a sort of type annotation.) It's not even a computation, unless you want to take a broad view and include oracles, interaction, etc. in your definition of computation. -Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 18:04, Donn Cave wrote: Quoth Steve Hornesh006d3...@blueyonder.co.uk, ... Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, code can be referential transparent and pure and at the same time use IO actions. In order to understand that, you need to untangle the notion you describe above as function result from Haskell function value. We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. To me, that only makes sense if you never run the compiled program - if the executable file is just an interesting artifact that you generated using a Haskell interpreter. In reality, the behaviour of IO actions is part of Haskell. The precise meaning of primitive Haskell IO actions is defined. The effects of compositing to build larger IO actions is defined. The Haskell language and compiler take responsibility for meaning of IO actions. The effect of executing those actions, including the returned values, is absolutely relevant to the behaviour of the program. You can make the argument that the world is a parameter. Well - in C, the world can be considered an implicit parameter. In any case, this only gives referential transparency by what I'd call deceptive definition. Only a tiny piece of the world is relevant to your program. You've buried the relevant in a mass of the irrelevant, very much like a less-than-transparent politician. Your interaction is no more or less likely to have bugs depending on whether you define this as transparent or not - arguing about the definition is besides the point. If a program that causes and is sensitive to side-effects - that interacts with the outside world - is referentially transparent, then referential transparency has no relevant meaning. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 18:41, Chris Smith wrote: Entering tutorial mode here... On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote: We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Not to nitpick, but I'm unsure what you might mean by function value there. An (IO Int) is not a function value: there is no function involved at all. I think the word function is causing some confusion, so I'll avoid calling things functions when they aren't. Except that it *is* a function value. Basically, a data constructor is a self-referencing function. Just 1 is a function that returns Just 1 for instance. According to WinGHCI... Prelude :type Just Just :: a - Maybe a Prelude The IO monad is a black box - we can't see the data constructors - but in principle it's the same thing. The value extracted out of the IO action when it is executed is a different thing, of course. These are PURE values... they do NOT have side effects. Perhaps they describe side effects in a sense, but that's a matter of how you interpret them; it doesn't change the fact that they play the role of ordinary values in Haskell. There are no special evaluation rules for them. The semantics of the execution of primitive IO actions are part of the Haskell language. The execution isn't pure functional. At compile-time there is no means to evaluate the key functions at all - no way to extract the result out of an IO action because the action cannot be executed and so doesn't (yet) have a result. At run-time, that restriction is removed, or the special evaluation rules are added in - either claim is fine but the effect that Haskell is doing something it couldn't do at compile-time. Yes, *Haskell* is doing it - it's still a part of what the Haskell language defines. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Gregg Reynolds wrote: Donn Cave wrote: Quoth Gregg Reynolds wrote: Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Ok, let's parse it out. …it's not the int you would get 'when executing this action. Close, but no cooky: it's not any kind of int at all (try doing arithmetic with it). IO Int is a piece of rhetoric for the mental convenience of the user; Haskell does not and cannot know what the result of an IO action is, because it's outside the scope of the language (and computation). (The Int part of IO Int refers to the input, not the output; it's just a sort of type annotation.) It's not even a computation, unless you want to take a broad view and include oracles, interaction, etc. in your definition of computation. Why would IO Int be something special or mysterious? It's an ordinary value like everything else; it's on the same footing as [Char], Maybe Int, Int - String, Bool, and so on. I see no difference between the list [1,2,3] :: [Int] and the action pick a random number between 1 and 6 :: IO Int . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 08:48, Heinrich Apfelmus wrote: ... Well, it's a matter of terminology: impure /= has side effects. The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. ... Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, code can be referential transparent and pure and at the same time use IO actions. In order to understand that, you need to untangle the notion you describe above as function result from Haskell function value. We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Again, this is nothing new - it's clear from SPJs Tackling the Awkward Squad that this is what the IO monad is meant for, and if it's evil then at least it's controlled evil. IO is not evil. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission deniedwhenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... Would this program then loop: append fromFilePath toFilePath = do str - readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Do you mean, locking makes that work, or just makes it fail in a different way? Anyway, I think that's an example that would have the same issues without hGetContents - that is, any way you set out to overwrite a file by modifying its contents, you have the same problem. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Steve Horne wrote: Heinrich Apfelmus wrote: Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, that's not my definition of impure. Also, my Haskell code is referentially transparent even though I'm using IO actions. If this sounds paradoxical, then it's probably worth mulling about some more. Maybe it helps to try to find an example of a function f :: A - B for some cleverly chosen types A,B that is not pure, i.e. does not return the same values for equal arguments. Chris Smith explains it very eloquently and Donn Cove and Jerzy Karczmarczuk say the same thing. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On Thu, Dec 29, 2011 at 11:49:11AM +, Andrew Coppin wrote: On 29/12/2011 04:29 AM, Antoine Latter wrote: On Wed, Dec 28, 2011 at 3:52 PM, Michael Snoymanmich...@snoyman.com wrote: Hi all, I just received a bug report from a client that, when an input file is open in FrameMaker, my program gives a permission denied error. This bug is reproducible with a simple Haskell program: This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The daft thing is, apparently Linux doesn't really support locking, so on that platform these types of thing all work fine, and only on Windows, which does and always has supported propper locking, people get these errors. And yet, many people seem surprised to hear that Windows can actually turn off the locking; they seem completely unaware of the extensive and highly flexible locking facilities that Windows provides. Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Sorry to say, but it seems you yourself are unaware of the extensive and highly flexible locking facilities on Linux :) The defaults on Linux are advisory locking, not mandatory, but claiming Linux doesn't support locking is plain wrong. regards, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. The result of an IO operation is outside of the control (and semantics) of the Haskell program, so Haskell has no idea what it will be. Within the program, there is no result. So Int - IO Int is not really a function - it does not map a determinate input to a determinate output. The IO monad just makes it look and act like a function, sort of, but what it really does is provide reliable ordering of non-functional operations - invariant order, not invariant results. To respond to original post: no language that supports IO can be purely functional in fact, but with clever design it can mimic a purely functional language. Cheers Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Quoth Steve Horne sh006d3...@blueyonder.co.uk, On 29/12/2011 18:41, Chris Smith wrote: ... On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote: We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Not to nitpick, but I'm unsure what you might mean by function value there. An (IO Int) is not a function value: there is no function involved at all. I think the word function is causing some confusion, so I'll avoid calling things functions when they aren't. Except that it *is* a function value. He's right, I should have omitted function, I just meant value. I think the rest of what came out when he entered tutorial mode should be very helpful, if there's anything left that remains to be clarified about how Haskell manages to be a pure functional language. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfilein use
On Thu, Dec 29, 2011 at 11:49 AM, Donn Cave d...@avvanta.com wrote: Quoth Antoine Latter aslat...@gmail.com, ... http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Wouldn't this lead to 'getContents' and friends being much less safe than they already are? Or would we have to do something at the GHC runtime level of things to add locking? Interesting question. I tend to steer clear of that function, rather than try to keep track of all the things that can go wrong with it! but I would guess, the effect is the same on any I/O strategy that executes the same way: e.g. if you were to read pieces of the file iteratively you would be similarly exposed to the possibility of concurrent modifications. That risk may be less obvious with getContents if you take the naive view that it returns the contents of the file in the same way that normal I/O operations return data, but then you will eventually be punished for that naivety anyway! Are you aware of some possible special issue with getContents? Well, the issue would more be with 'hGetContents'. Would this program then loop: append fromFilePath toFilePath = do str - readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Convert Double to Data.Fixed
On 11-12-26 10:55 AM, Eugene Kirpichov wrote: How do I most efficiently convert a Double to a Data.Fixed? Double is an instance of Real, Fixed E12 is an instance of Fractional, they are eligible for realToFrac. Similarly for many time types. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Dec 29, 2011, at 11:29 AM, Antoine Latter wrote: On Thu, Dec 29, 2011 at 11:14 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote: And to clarify better my original email: yes, (bar x) always gives you back the same IO action; More precisely: the same *type*. I'm confused - what do you mean by type? I don't think that Iustin's statement needs any sort of qualifier - (bar x) always returns the same IO action when called with the same value for x, no matter how many times you call it. Maybe it doesn't need qualification, but my guess is that most people read IO Int to mean something like IO action of type int. But computation does not involve action. Action is just an explanatory device - a kind of macguffin - to help explain what's going on with IO, which is non-computational. But it is a type, and in Haskell it's all about the types. IO Int is a type designator, not an action designator. A minor point maybe, but germane to the original post (I hope). -Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Sorry to say, but it seems you yourself are unaware of the extensive and highly flexible locking facilities on Linux :) The defaults on Linux are advisory locking, not mandatory, but claiming Linux doesn't support locking is plain wrong. I would suggest that advisory locking isn't particularly useful. I gather that Linux does now support real locking though. (And file update notifications, and ACLs, and lots of other things that Windows has had for far longer.) Either way, I have no interest in starting a Windows vs Linux flamewar. I'm just saying it would be nice if Haskell could support more of what these two OSes have to offer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
29.12.2011, 23:55, Gregg Reynolds d...@mobileink.com: Haskell does not and cannot know what the result of an IO action is, because it's outside the scope of the language (and computation). (The Int part of IO Int refers to the input, not the output; it's just a sort of type annotation.) It's not even a computation, unless you want to take a broad view and include oracles, interaction, etc. in your definition of computation. Yes, purity is a property of language. It's matter to thinking of algorithms and expressing these algorithms in computer language. It's not matter (in general) for programmers what PC would be do with IO computation. We want to have an expressive instrument and want to have a robust language. We want to have a language that can give us possibility to express our algorithms in clear, easy to understand, proven ways. And purity property of language is about it. It's not interesting to programmers what means purity to compile or to runtime system. It maybe interesting if we can realize effective compiler form language with purity property to machine codes. But haskell shows us than it's possible. Isn't it? --- PS sorry for my not good French ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Thu, Dec 29, 2011 at 11:14 AM, Gregg Reynolds d...@mobileink.com wrote: On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote: And to clarify better my original email: yes, (bar x) always gives you back the same IO action; More precisely: the same *type*. I'm confused - what do you mean by type? I don't think that Iustin's statement needs any sort of qualifier - (bar x) always returns the same IO action when called with the same value for x, no matter how many times you call it. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfilein use
Quoth Antoine Latter aslat...@gmail.com, ... http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Wouldn't this lead to 'getContents' and friends being much less safe than they already are? Or would we have to do something at the GHC runtime level of things to add locking? Interesting question. I tend to steer clear of that function, rather than try to keep track of all the things that can go wrong with it! but I would guess, the effect is the same on any I/O strategy that executes the same way: e.g. if you were to read pieces of the file iteratively you would be similarly exposed to the possibility of concurrent modifications. That risk may be less obvious with getContents if you take the naive view that it returns the contents of the file in the same way that normal I/O operations return data, but then you will eventually be punished for that naivety anyway! Are you aware of some possible special issue with getContents? Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission deniedwhenfilein use
On Thu, Dec 29, 2011 at 12:28 PM, Donn Cave d...@avvanta.com wrote: Quoth Antoine Latter aslat...@gmail.com, ... Would this program then loop: append fromFilePath toFilePath = do str - readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Do you mean, locking makes that work, or just makes it fail in a different way? Anyway, I think that's an example that would have the same issues without hGetContents - that is, any way you set out to overwrite a file by modifying its contents, you have the same problem. Locking makes this fail with an exception, I think. Not locking would make this mis-behave. And lets pretend I wrote the function that was in my head: append fromFilePath toFilePath = do str - readFile fromFile appendFile toFile str Here, without locking, I would expect to fill my disk up, whereas previously my program would have crashed before writing out any data. Maybe these are pathological examples, but they are (I think!) the justification for having the locking in the first place. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Here's an alternative perspective to consider: consider some data structure, such as a queue. There are two ways you can implement this, one the imperative way, with mutators, and the other the purely functional way, with no destructive updates. The question then, I ask, is how easy does a programming language make it to write the data structure in the latter fashion? How easy is it for you to cheat? Edward Excerpts from Steve Horne's message of Wed Dec 28 12:39:52 -0500 2011: This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs Tackling the Awkward Squad. I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction. Warning - it may look like trolling at various points. Please keep going to the end before making a judgement. To make the context explicit, there are two apparently conflicting viewpoints on Haskell... 1. The whole point of the IO monad is to support programming with side-effecting actions - ie impurity. 2. The IO monad is just a monad - a generic type (IO actions), a couple of operators (primarily return and bind) and some rules - within a pure functional language. You can't create impurity by taking a subset of a pure language. My view is that both of these are correct, each from a particular point of view. Furthermore, by essentially the same arguments, C is also both an impure language and a pure one. See what I mean about the trolling thing? I'm actually quite serious about this, though - and by the end I think Haskell advocates will generally approve. First assertion... Haskell is a pure functional language, but only from the compile-time point of view. The compiler manipulates and composes IO actions (among other things). The final resulting IO actions are finally swallowed by unsafePerformIO or returned from main. However, Haskell is an impure side-effecting language from the run-time point of view - when the composed actions are executed. Impurity doesn't magically spring from the ether - it results from the translation by the compiler of IO actions to executable code and the execution of that code. In this sense, IO actions are directly equivalent to the AST nodes in a C compiler. A C compiler can be written in a purely functional way - in principle it's just a pure function that accepts a string (source code) and returns another string (executable code). I'm fudging issues like separate compilation and #include, but all of these can be resolved in principle in a pure functional way. Everything a C compiler does at compile time is therefore, in principle, purely functional. In fact, in the implementation of Haskell compilers, IO actions almost certainly *are* ASTs. Obviously there's some interesting aspects to that such as all the partially evaluated and unevaluated functions. But even a partially evaluated function has a representation within a compiler that can be considered an AST node, and even AST nodes within a C compiler may represent partially evaluated functions. Even the return and bind operators are there within the C compiler in a sense, similar to the do notation in Haskell. Values are converted into actions. Actions are sequenced. Though the more primitive form isn't directly available to the programmer, it could easily be explicitly present within the compiler. What about variables? What about referential transparency? Well, to a compiler writer (and equally for this argument) an identifier is not the same thing as the variable it references. One way to model the situation is that for every function in a C program, all explicit parameters are implicitly within the IO monad. There is one implicit parameter too - a kind of IORef to the whole system memory. Identifiers have values which identify where the variable is within the big implicit IORef. So all the manipulation of identifiers and their reference-like values is purely functional. Actual handling of variables stored within the big implicit IORef is deferred until run-time. So once you accept that there's an implicit big IORef parameter to every function, by the usual definition of referential transparency, C is as transparent as Haskell. The compile-time result of each function is completely determined by its (implicit and explicit) parameters - it's just that that result is typically a way to look up the run-time result within the big IORef later. What's different about Haskell relative to C therefore... 1. The style of the AST is different. It still amounts to the same thing in this argument, but the fact that most AST nodes are simply partially-evaluated functions has significant practical
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On Thu, Dec 29, 2011 at 12:20:18PM +, Andrew Coppin wrote: Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Sorry to say, but it seems you yourself are unaware of the extensive and highly flexible locking facilities on Linux :) The defaults on Linux are advisory locking, not mandatory, but claiming Linux doesn't support locking is plain wrong. I would suggest that advisory locking isn't particularly useful. In my experience (as an application writer) it is very useful; it's just a different paradigm, not a weaker one. Off-hand I don't remember a case where having mandatory locking would have improved things. I gather that Linux does now support real locking though. (And file update notifications, and ACLs, and lots of other things that Windows has had for far longer.) Hrmm: Mandatory File Locking For The Linux Operating System, 15 April 1996 :) Either way, I have no interest in starting a Windows vs Linux flamewar. Me neither - I just wanted to point out that your email sounded _too_ eager to blame the current state of affairs on the fact that Linux doesn't support proper locking. Whereas, the problem is just one of taking into account platform differences better. I'm just saying it would be nice if Haskell could support more of what these two OSes have to offer. Totally agreed! all the best, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le 29/12/2011 18:01, Iustin Pop a écrit : I'm confused as what you mean. And to clarify better my original email: yes, (bar x) always gives you back the same IO action; but the results of said IO action are/can be different when executed. The whole of my point is that it DOESN'T MATTER. (And I believe that Heinrich A. meant the same thing). I asked for the execution trace in order that you see what your function does to the programme itself, not that it attempts to contact the external world, and explode it. You discovered it yourself. The result is an object of type Read a = IO a and this is all. (Well, in order to really execute it, you have to specify the type a anyway). I think that nobody will convince anybody here. Steve Horne continues with his own visions : /if you're using IO actions, your code is not referentially transparent and is therefore impure/ I believe that this statement is doubly erroneous, but I give up. I won't even ask to show me WHERE the ref. transparence is broken. This discussion is a dead loop... Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote: Iustin Pop:: In practice too: bar _ = do s- readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. Nice example. PLEASE, show us the trace of its execution. Then, the discussion might be more fruitful Sorry? I did the same mistake of misreading the grand-parent's IO Int vs. Int, if that's what you're referring to. Otherwise, I'm confused as what you mean. iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
I gather that Linux does now support real locking though. (And file update notifications, and ACLs, and lots of other things that Windows has had for far longer.) Hrmm: Mandatory File Locking For The Linux Operating System, 15 April 1996 :) Have a reference for when it was actually implemented? I tried to look this up, and got this: http://0pointer.de/blog/projects/locking.html Sounds like it's not so solved after all. (Or perhaps the author just doesn't know enough about it, it's hard to say...) The Wikipedia page on file locking also points out a list of Unix-related locking problems. (But again, that might just be editor bias.) I'm just saying it would be nice if Haskell could support more of what these two OSes have to offer. Totally agreed! Good, that was my main point. Now, who's volunteering to implement all this? :-} ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 19:21, Heinrich Apfelmus wrote: Why would IO Int be something special or mysterious? It's an ordinary value like everything else; it's on the same footing as [Char], Maybe Int, Int - String, Bool, and so on. I see no difference between the list [1,2,3] :: [Int] and the action pick a random number between 1 and 6 :: IO Int . Because performing the action (as part of extracting the result out of it) is relevant to the semantics of the language too, whether an IO monadic random generator or an an interaction with the user via a GUI or whatever. BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfile in use
On Thu, Dec 29, 2011 at 10:53 AM, Donn Cave d...@avvanta.com wrote: Quoth Andrew Coppin andrewcop...@btinternet.com, On 29/12/2011 04:29 AM, Antoine Latter wrote: ... This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The rationale that followed may have been a little sketchy, but apparently everyone agrees with with the point. I see the ticket led to a discussion on the libraries list - http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Wouldn't this lead to 'getContents' and friends being much less safe than they already are? Or would we have to do something at the GHC runtime level of things to add locking? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied whenfile in use
Quoth Andrew Coppin andrewcop...@btinternet.com, On 29/12/2011 04:29 AM, Antoine Latter wrote: ... This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The rationale that followed may have been a little sketchy, but apparently everyone agrees with with the point. I see the ticket led to a discussion on the libraries list - http://www.haskell.org/pipermail/libraries/2011-October/016978.html ... wherein Ian Lynagh proposed to remove this feature and let the programmer enforce locking or not, as in other programming languages' base I/O libraries. This met with enthusiastic universal support, so whatever the Report may say, it looks to me like the GHC libraries will eventually not do this. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Of course we take in matter what computation getStr :: IO [Char] means. Of course we take in matter what computation putStr :: String - IO () means (I know, putStr is not computation, puStr x is computation, but it's not important) And If I want to write echo program, I have to combine these computation in such manner: echo = do s - getStr putStr s But for geometry I have similarly situation. I know arithmetics and I know Pythagoras theorem and I combine arithmetics operations to get length of hypotéinusa: h x y = sqrt $ x * x + y * y. What is difference of IO actions and PURE operation *? I have to know meaning of getStr action but I have to know meaning of * operation. Side effects appears in impure languages when we can different results of function (procedure etc) with same parameters. For example, when our function use global (modifible) variable. But we WANT that ours function (Int - Int, Char - [a], b - IO a - it's not matter) will be PURE, becourse it makes life of programmers easy. But I don't understand importance of thinking about side effects in dilemma of language vs compiled pogramm. 30.12.2011, 02:21, Heinrich Apfelmus apfel...@quantentunnel.de: Gregg Reynolds wrote: Donn Cave wrote: Quoth Gregg Reynolds wrote: Look again at the sentence you trimmed off the end: Of course, the point is that this result is an *IO action* of type IO Int, it's not the Int you would get when executing this action. I believe that more or less points to the key to this discussion. If it didn't make sense to you, or didn't seem relevant to the question of pure functions, then it would be worth while to think more about it. Ok, let's parse it out. …it's not the int you would get 'when executing this action. Close, but no cooky: it's not any kind of int at all (try doing arithmetic with it). IO Int is a piece of rhetoric for the mental convenience of the user; Haskell does not and cannot know what the result of an IO action is, because it's outside the scope of the language (and computation). (The Int part of IO Int refers to the input, not the output; it's just a sort of type annotation.) It's not even a computation, unless you want to take a broad view and include oracles, interaction, etc. in your definition of computation. Why would IO Int be something special or mysterious? It's an ordinary value like everything else; it's on the same footing as [Char], Maybe Int, Int - String, Bool, and so on. I see no difference between the list [1,2,3] :: [Int] and the action pick a random number between 1 and 6 :: IO Int . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ 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] On the purity of Haskell
Quoth Gregg Reynolds d...@mobileink.com, .. A minor point maybe, but germane to the original post (I hope). It isn't - I mean, I'm not really sure what your point is, but the example really returns the same IO value, not just one of the same type. Consider an example with implementation: wint :: Int - IO Int wint a = let s = show a in do putStr s return (length s) Now the expression wint 994 is a value of type IO Int, and any instance of that expression is the same value - an action is not the same as the action's result. You can use this value in pure Haskell expressions with confidence. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On 29/12/2011 04:29 AM, Antoine Latter wrote: On Wed, Dec 28, 2011 at 3:52 PM, Michael Snoymanmich...@snoyman.com wrote: Hi all, I just received a bug report from a client that, when an input file is open in FrameMaker, my program gives a permission denied error. This bug is reproducible with a simple Haskell program: This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The daft thing is, apparently Linux doesn't really support locking, so on that platform these types of thing all work fine, and only on Windows, which does and always has supported propper locking, people get these errors. And yet, many people seem surprised to hear that Windows can actually turn off the locking; they seem completely unaware of the extensive and highly flexible locking facilities that Windows provides. Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Whatever we change the default to, it would be useful if we could expose locking mechanisms in a reasonably portable way so that people who care about such things can alter the default if it is not what they want. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Thu, Dec 29, 2011 at 05:55:24PM +0100, Iustin Pop wrote: On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote: Iustin Pop:: In practice too: bar _ = do s- readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. Nice example. PLEASE, show us the trace of its execution. Then, the discussion might be more fruitful Sorry? I did the same mistake of misreading the grand-parent's IO Int vs. Int, if that's what you're referring to. Otherwise, I'm confused as what you mean. And to clarify better my original email: yes, (bar x) always gives you back the same IO action; but the results of said IO action are/can be different when executed. iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Dec 29, 2011, at 11:01 AM, Iustin Pop wrote: On Thu, Dec 29, 2011 at 05:55:24PM +0100, Iustin Pop wrote: On Thu, Dec 29, 2011 at 05:51:57PM +0100, Jerzy Karczmarczuk wrote: Iustin Pop:: In practice too: bar _ = do s- readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. Nice example. PLEASE, show us the trace of its execution. Then, the discussion might be more fruitful Sorry? I did the same mistake of misreading the grand-parent's IO Int vs. Int, if that's what you're referring to. Otherwise, I'm confused as what you mean. And to clarify better my original email: yes, (bar x) always gives you back the same IO action; More precisely: the same *type*. but the results of said IO action are/can be different when executed. -Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le Thu, 29 Dec 2011 01:03:34 +, Steve Horne sh006d3...@blueyonder.co.uk a écrit : Sorry for the delay. I've written a couple of long replies already, and both times when I'd finished deleting all the stupid stuff there was nothing left - it seems I'm so focussed on my own view, I'm struggling with anything else today. Maybe a third try... On 28/12/2011 19:38, AUGER Cédric wrote: Le Wed, 28 Dec 2011 17:39:52 +, Steve Hornesh006d3...@blueyonder.co.uk a écrit : This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs Tackling the Awkward Squad. I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction. IO monad doesn't make the language impure for me, since you can give another implementation which is perfectly pure and which has the same behaviour (although completely unrealistic): Now how would this work? In a first time, you load all your system file before running the program (a side-effect which does not modify already used structures; it is just initialization), then you run the program in a perfectly pure way, and at the end you commit all to the system file (so you modify structures the running program won't access as it has terminated). I don't see how interactivity fits that model. If a user provides input in response to an on-screen prompt, you can't do all the input at the start (before the prompt is delayed) and you can't do all the output at the end. Yes and no, in fact you can think of interactivity as a component of the environment (you can also tell that stdin is the file of what will be input) and the IO system as causality guardness (ie, you are not allowed to pick an input before prompting the query). Other than that, I'm OK with that. In fact if you're writing a compiler that way, it seems fine - you can certainly delay output of the generated object code until the end of the compilation, and the input done at the start of the compilation (source files) is separate from the run-time prompt-and-user-input thing. See - I told you I'm having trouble seeing things in terms of someone elses model - I'm back to my current obsession again here. In Haskell, 'hGetChar h= \c - hPutChar i' always has the same value, but 'trans (hGetChar h= \c - hPutChar i) (IO_ A)' 'trans (hGetChar h= \c - hPutChar i) (IO_ B)' may have different values according to A and B. In C, you cannot express this distinction, since you only have: 'read(h,c, 1); write(i,c, 1);' and cannot pass explicitely the environment. Agreed. Haskell is definitely more powerful in that sense. There have been a lot of answers in this thread, but I didn't see one about what I posted: I encountered a situation where my vision of things was broken: hGetContents :: Handle - IO ByteString in Data.ByteString.Lazy as BS The following two programs BS.hGetContents h = \b - close h let x = BS.length b in print x -- ^ Dangerous, never do it! BS.hGetContents h = \b - let x = BS.length b in close h print x -- ^ The right way to do is a problem for me, as BS.length doesn't receive an environment as a parameter, so as they are given the SAME b, they should give the same result. (For me all BS.ByteString operations should be done inside a Monad; the non-lazy ByteString doesn't have this problem of course) *** In fact I am not sure there will be a problem with the BS.length, but I had one in a very similar situation, for me the referential transparency was broken. How to interpret that? Is it some ugly thing to keep compliant with the non Lazy? Is it perfectly ok with the semantics, but I misunderstand the semantics? Is it some inconsistency nobody thought of? (although I have seen some very similar comment in this thread) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Entering tutorial mode here... On Thu, 2011-12-29 at 10:04 -0800, Donn Cave wrote: We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell program it's a simple function value, e.g., IO Int. Not to nitpick, but I'm unsure what you might mean by function value there. An (IO Int) is not a function value: there is no function involved at all. I think the word function is causing some confusion, so I'll avoid calling things functions when they aren't. In answer to the original question, the mental shift that several people are getting at here is this: a value of the type (IO Int) is itself a meaningful thing to get your hands on and manipulate. IO isn't just some annotation you have to throw in to delineate where your non-pure stuff is or something like that; it's a type constructor, and IO types have values, which are just as real and meaningful as any other value in the system. For example, Type: Int Typical Values: 5, or 6, or -11 Type: IO Int Typical Values: (choosing a random number from 1 to 10 with the default random number generator), or (doing nothing and always returning 5), or (writing hello to temp.txt in the current working directory and returning the number of bytes written) These are PURE values... they do NOT have side effects. Perhaps they describe side effects in a sense, but that's a matter of how you interpret them; it doesn't change the fact that they play the role of ordinary values in Haskell. There are no special evaluation rules for them. Just like with any other type, you might then consider what operations you might want on values of IO types. For example, the operations you might want on Int are addition, multiplication, etc. It turns out that there is one major operation you tend to want on IO types: combine two of them by doing them in turn, where what you do second might depend on the result of what you do first. So we provide that operation on values of IO types... it's just an ordinary function, which happens to go by the name (=). That's completely analogous to, say, (+) for Int... it's just a pure function that takes two parameters, and produces a result. Just like (+), if you apply (=) to the same two parameters, you'll always get the same value (of an IO type) as a result. Now, of course, behind the scenes we're using these things to describe effectful actions... which is fine! In fact, our entire goal in writing any computer program in any language is *precisely* to describe an effectful action, namely what we'd like to see happen when our program is run. There's nothing wrong with that... when Haskell is described as pure, what is meant by that is that is lets us get our hands on these things directly, manipulate them by using functions to construct more such things, in exactly the same way we'd do with numbers and arithmetic. This is a manifestly different choice from other languages where those basic manipulations even on the simple types are pushed into the more nebulous realm of effectful actions instead. If you wanted to make a more compelling argument that Haskell is not pure, you should look at termination and exceptions from pure code. This is a far more difficult kind of impurity to explain away: we do it, by introducing a special families of values (one per type) called bottom or _|_, but then we also have to introduce some special-purpose rules about functions that operate on that value... an arguably clearer way to understand non-termination is as a side-effect that Haskell does NOT isolate in the type system. But that's for another time. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 10:05, Jerzy Karczmarczuk wrote: Sorry, a long and pseudo-philosophical treatise. Trash it before reading. Heinrich Apfelmus: You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. I have no reason to be categorical, but I believe that calling the interaction of a Haskell programme with the World - a side effect is sinful, and it is a source of semantical trouble. People do it, SPJ (cited by S. Horne) did it as well, and this is too bad. People, when you eat a sandwich: are you doing side effects?? If you break a tooth on it, this IS a side effect, but neither the eating nor digesting it, seems to be one. By definition, an intentional effect is a side-effect. To me, it's by deceptive redefinition - and a lot of arguments rely on mixing definitions - but nonetheless the jargon meaning is correct within programming and has been for decades. It's not going to go away. Basically, the jargon definition was coined by one of the pioneers of function programming - he recognised a problem and needed a simple way to describe it, but in some ways the choice of word is unfortunate. The important thing is to make sure that the explanations you trust aren't based on mixing of the jargon and everyday meanings of side-effect. In part that's what my original e-mail is about - accepting the definitions of side-effect and referential transparency that are standard within functional programming, eliminating the common non-sequiturs and seeing if functional programming really does still make sense at the end. What would have surprised me when I started this unintentional journey (each step basically being a rant at one functional programming advocate or another) is that actually functional programming in Haskell really does make sense. This term should be used in a way compatible with its original meaning, that something happens implicitly, behind the curtain, specified most often in an informal way (not always deserving to be called operational). If you call all the assignments side effects, why not call - let x = whatever in Something - also a local side-effect? Oh, that you can often transform let in the application of lambda, thus purely functional? Doesn't matter, Steve Horne will explain you that (sorry for the irony): let is a compile-time pure construct ; at execution this is impure, because x got a value. Well, I was even more absurd than that - in C, I said there were two values (the reference and the value referenced) for every variable. Sometimes, eliminating all the subtle contradictions necessarily leads to a much more pedantic world than intuition is happy to deal with. S.H. admits that he reasons within his model, and has problems with others. Everybody has such problems, but I see here something the (true) Frenchies call un dialogue de sourds. For me a Haskell programme is ABSOLUTELY pure, including the IO. The issue is that `bind` within the IO monad has an implicit parameter, the World. In fact, a stream of Worlds, every putWhatever, getLine, etc. passes to a new instance. As I said earlier, a politician who buries the relevant in a huge mass of the irrelevant is not considered transparent. To call this world parameter referentially transparent is, to me, argument by deceptive definitions. In any case, the world parameter is present in C - it's just implicit. You can translate C to Haskell and visa versa. Both the C and Haskell versions of a correctly translated program will have the same interactions with the world. Therefore there is a mathematical equivalence between Haskell and C. You can argue pedantry, but the pedantry must have a point - a convenient word redefinition will not make your bugs go away. People tried that with it's not a bug it's a feature and no-one was impressed. Simply, you are not allowed by the Holy Scripts to look under this robe. Ah yes - well that's exactly what I'm trying to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Iustin Pop:: In practice too: bar _ = do s- readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. Nice example. PLEASE, show us the trace of its execution. Then, the discussion might be more fruitful Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Thu, Dec 29, 2011 at 07:19:17AM -0600, Gregg Reynolds wrote: On Wed, Dec 28, 2011 at 2:44 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: The beauty of the IO monad is that it doesn't change anything about purity. Applying the function bar :: Int - IO Int to the value 2 will always give the same result: bar 2 = bar (1+1) = bar (5-3) Strictly speaking, that doesn't sound right. The result of an IO operation is outside of the control (and semantics) of the Haskell program, so Haskell has no idea what it will be. Within the program, there is no result. So Int - IO Int is not really a function - it does not map a determinate input to a determinate output. The IO monad just makes it look and act like a function, sort of, but what it really does is provide reliable ordering of non-functional operations - invariant order, not invariant results. Not only strictly speaking. In practice too: bar _ = do s - readFile /tmp/x.txt return (read s) Once you're in a monad that has 'state', the return value doesn't strictly depend anymore on the function arguments. At least that's my understanding. regards, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] data-structure-inferrer, standard library on steroids
Hi,
I'm writing a project and was wondering what other people think about it.
This project is meant to be a compiler feature/wrapper that analyzes your
code and chooses the best data structure depending on your source code. It
analyzes the functions used on a wildcard data structure and chooses the
type of structure that minimizes the time complexity. It nearly supports C
language and hopefully some other languages too. The purpose is that you
don't have to care which data structure to use ever again :D (hopefully, if
it works well, lol).
Maybe some illustrative examples:
int main()
{
ds d; //data structure
while(something) {
insert(d, 5);
}
while(!empty(d)) {
printf(%d\n, max(d));
delete_max(d);
}
}
Here dsinf would infer some kind of a heap (or possibly a rbt with max
element cache).
int main()
{
ds d; //data structure
while(something)
insert(d, 5);
while(something)
update(d, 2, 7);
while(something)
delete(d, 1);
printf(25 is in the set, search(d, 25));
}
Here it would be hashtable (it differs from the earlier, because we don't
need element ordering).
if anybody wants to hack it, the C api is in dsimp/ds.h and some tests in
C/tests/.
I have some ideas how to extend it from trivial cases, the ideas are in
github issues.
repo: git clone https://github.com/alistra/data-structure-inferrer.git
hackage: http://hackage.haskell.org/package/data-structure-inferrer-1.0
So just let me know what you think ;]
Also does anybody know a good ~MIT licenced library of data structures
written in C (they're needed for the auto-compile option)?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
If seed depends of psudo random event, for example of current systime, we must use IO action. 30.12.2011, 02:47, Steve Horne sh006d3...@blueyonder.co.uk: BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. ___ 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] On the purity of Haskell
On 12/29/2011 08:47 PM, Steve Horne wrote: On 29/12/2011 19:21, Heinrich Apfelmus wrote: BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. *Pseudo* random number generation can of course be pure (though threading the state would be tedious and error-prone). If you want truly random numbers you cannot avoid IO (the monad). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Dec 29, 2011, at 12:33 PM, Donn Cave wrote: Quoth Gregg Reynolds d...@mobileink.com, .. A minor point maybe, but germane to the original post (I hope). It isn't - I mean, I'm not really sure what your point is, but the example really returns the same IO value, not just one of the same type. Consider an example with implementation: wint :: Int - IO Int wint a = let s = show a in do putStr s return (length s) Now the expression wint 994 is a value of type IO Int, and any instance of that expression is the same value Ok, but if that were all there is to it we would not need monads. I guess it may boil down to a matter of taste in definition and exposition - to me any account of stuff like IO Int that omits mention of the fact that, well, IO is involved, is incomplete. But then I like the theoretical and even philosophical side of things where others tend to want to get on with writing useful code. ;) And the original post was if I remember about purity/impurity etc. - an action is not the same as the action's result. Nor is a computation the same as the computation's result. The critical difference is that computations are deterministic processes, and actions (IO, rand, etc.) are not. Therefore they are not functions, their evaluation must be ordered, and they cannot even in principle be fully modeled in purely functional terms. At least I don't see how they can. You can use this value in pure Haskell expressions with confidence. Because they are monadic, not because they are values like other values. -Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 19:26, Heinrich Apfelmus wrote: Steve Horne wrote: Heinrich Apfelmus wrote: Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of function within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of impure. Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the outside - clearly means that some of your function results are dependent on what's happening outside your program. That includes side-effects outside your program yet caused by program program. No, that's not my definition of impure. Also, my Haskell code is referentially transparent even though I'm using IO actions. If this sounds paradoxical, then it's probably worth mulling about some more. Maybe it helps to try to find an example of a function f :: A - B for some cleverly chosen types A,B that is not pure, i.e. does not return the same values for equal arguments. That doesn't prove Haskell pure. Of course your challenge looks like a safe one. It can't be done because the IO monad is a black box - you can't e.g. pattern-match on it's data constructors. Of course you can extract values out of IO actions to work with them - the bind operator does this for you nicely, providing the value as an argument to the function you pass to the right-hand argument of the bind. But that function returns another IO action anyway - although you've extracted a value out and the value affects a computation, all you can do with it in the long run is return another IO action. Even so, that value can only be extracted out at run-time, after the action is executed. So, consider the following... getAnIntFromTheUser :: IO Int From a pure functional point of view, that should return the same action every time. Well, the partially evaluated getAnIntFromTheUser has the same structure each time - but the actual Int packaged inside the action isn't decided until runtime, when the action is executed. At compile-time, that action can only be partially evaluated - the final value OF THE ACTION depends on what Int the user chooses to give because that Int is a part of the action value. For your specific challenge, place that as a left-hand argument in a bind... f :: Int - IO Int f = getAnIntFromTheUser = \i - return (i+1) Well, the value of i isn't decidable until runtime. The value of i+1 is not decidable until runtime. The value of return (i+1) is not decidable until runtime and so on. It can only be partially evaluated at compile-time, but when it is fully evaluated, you get a different IO action returned by f depending on what Int you got from the user. And so we get right back to the referential-transparency-by-referencing-the-world-as-an-argument thing, I guess. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Dec 29, 2011, at 1:21 PM, Heinrich Apfelmus wrote: Why would IO Int be something special or mysterious? I don't know if it is special or mysterious, but I'm pretty sure IO is non-deterministic, non-computable, etc. In other words not the same as computation. It's an ordinary value like everything else; it's on the same footing as [Char], Maybe Int, Int - String, Bool, and so on. I see no difference between the list [1,2,3] :: [Int] and the action pick a random number between 1 and 6 :: IO Int . We'll have to agree to disagree - I see a fundamental difference. But that's ok, nothing says everybody has to agree on the One True Way to think about computing. Cheers, Gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 19:55, Bardur Arantsson wrote: On 12/29/2011 08:47 PM, Steve Horne wrote: On 29/12/2011 19:21, Heinrich Apfelmus wrote: BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. *Pseudo* random number generation can of course be pure (though threading the state would be tedious and error-prone). If you want truly random numbers you cannot avoid IO (the monad). On the threading the state thing - it doesn't matter whether it's the IO monad or the State monad (a perfect wrapper for the seed). For where-does-the-entropy-come-from, though, yes - I guess you're right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On the purity of Haskell /Random generators
The story begins here: Steve Horne: /BTW - why use an IO action for random number generation? There's a perfectly good pure generator. It's probably handy to treat it monadically to sequence the generator state/seed/whatever but random number generation can be completely pure. / === Bardur Arantsson: /*Pseudo* random number generation can of course be pure (though threading the state would be tedious and error-prone). If you want truly random numbers you cannot avoid IO (the monad). / ??? ??? : If seed depends of psudo random event, for example of current systime, we must use IO action. Bardur, Lev, of course you try to be helpful, but you are answering wrong questions. Truly random numbers are very rarely used, forget about them. Standard r. generators (pseudo-random) in Haskell are monadic, because the relevant algorithms are stateful. Congruential, Fibonacci, Mersenne Twister, whatever, is a function, more or less: (newValue,newSeed) = rgen seed The monadic approach serves mainly to hide the seed. Some people prefer to use random streams, no monads, so the question of Steve Horne is not universal. But anyway, even without bind, the user will have to chain the seeds in some way. Still, I dont understand what does S.H. mean by a perfectly good pure generator. Tell more please (unless you just mean a stream, say: str = map fst (iterate (\(v,sd) - rgen sd) (v0,sd0)) ) Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote: By definition, an intentional effect is a side-effect. To me, it's by deceptive redefinition - and a lot of arguments rely on mixing definitions - but nonetheless the jargon meaning is correct within programming and has been for decades. It's not going to go away. Basically, the jargon definition was coined by one of the pioneers of function programming - he recognised a problem and needed a simple way to describe it, but in some ways the choice of word is unfortunate. I don't believe this is true. Side effect refers to having a FUNCTION -- that is, a map from input values to output values -- such that when it is evaluated there is some effect in addition to computing the resulting value from that map. The phrase side effect refers to a very specific confusion: namely, conflating the performing of effects with computing the values of functions. Haskell has no such things. It's values of IO types are not functions at all, and their effects do not occur as a side effect of evaluating a function. Kleisli arrows in the IO monad -- that is, functions whose result type is an IO type, for example String - IO () -- are common, yes, but note that even then, the effect still doesn't occur as a side effect of evaluating the function. Evaluating the function just gives you a specific value of the IO type, and performing the effect is still a distinct step that is not the same thing as function evaluation. You can argue pedantry, but the pedantry must have a point - a convenient word redefinition will not make your bugs go away. People tried that with it's not a bug it's a feature and no-one was impressed. This most certainly has a point. The point is that Haskell being a pure language allows you to reason more fully about Haskell programs using basic language features like functions and variables. Yes, since Haskell is sufficiently powerful, it's possible to build more and more complicated constructs that are again harder to reason about... but even when you do so, you end up using the core Haskell language to talk *about* such constructs... you retain the ability to get your hands on them and discuss them directly and give them names, not mere as side aspects of syntactic forms as they manifest themselves in impure languages. That is the point of what people are saying here (pedantry or not is a matter of your taste); it's directly relevant to day to day programming in Haskell. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
On 29/12/2011 20:39, Jerzy Karczmarczuk wrote: Still, I dont understand what does S.H. mean by a perfectly good pure generator. Tell more please (unless you just mean a stream, say: Probably bad wording, to be honest. I only meant that there's random number handling support in the Haskell library and, and least judging by type signatures, it's pure functional code with no hint of the IO monad. AFAIK there's no hidden unsafePerformIO sneaking any entropy in behind the scenes. Even if there was, it might be a legitimate reason for unsafePerformIO - random numbers are in principle non-deterministic, not determined by the current state of the outside world and which-you-evaluate-first should be irrelevant. If you have a quantum genuine-random-numbers gadget, the IO monad might be considered redundant for functions that get values from it - though it still isn't referentially transparent as it returns a different value each time even with the same parameters. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
On Thu, 2011-12-29 at 21:04 +, Steve Horne wrote: AFAIK there's no hidden unsafePerformIO sneaking any entropy in behind the scenes. Even if there was, it might be a legitimate reason for unsafePerformIO - random numbers are in principle non-deterministic, not determined by the current state of the outside world and which-you-evaluate-first should be irrelevant. This is certainly not legitimate. Anything that can't be memoized has no business advertising itself as a function in Haskell. This matters quite a lot... programs might change from working to broken due to something as trivial as inlining by the compiler (see the ugly NOINLINE annotations often used with unsafePerformIO tricks for initialization code for an example). -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
Steve Horne : I only meant that there's random number handling support in the Haskell library and, and least judging by type signatures, it's pure functional code with no hint of the IO monad. Look well at those functions, please. Within the RandomGen class you have pure members, such as next (an Int instance of what I called rgen in my previous message. It propagates the seed g ). The algorithmics of the random generation has no particular monadicity in it, as I said, the IO (or State) monad serves to hide the seed. The generator itself should not be confounded with its iterative, sequential usage. If people wanted to do in their programmes just *one* read or write, never repeated, no IO Monad would be necessary. On the other hand, for the IO, you can sequence the World instances explicitly, without any Monads in a pure functional language, this is the style used in Clean. == I am strongly convinced that ALL people who want to understand the functional IO, refs, etc. should learn both, Haskell and Clean. Il might help them to see better the relation between the programme, and its environment. == You say: /random numbers are in principle non-deterministic, not determined by the current state of the outside world/ Sorry, but I haven't a slightest idea what you are talking about. Dybbuks? Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 21:01, Chris Smith wrote: On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote: By definition, an intentional effect is a side-effect. To me, it's by deceptive redefinition - and a lot of arguments rely on mixing definitions - but nonetheless the jargon meaning is correct within programming and has been for decades. It's not going to go away. Basically, the jargon definition was coined by one of the pioneers of function programming - he recognised a problem and needed a simple way to describe it, but in some ways the choice of word is unfortunate. I don't believe this is true. Side effect refers to having a FUNCTION -- that is, a map from input values to output values -- such that when it is evaluated there is some effect in addition to computing the resulting value from that map. The phrase side effect refers to a very specific confusion: namely, conflating the performing of effects with computing the values of functions. Yes - again, by definition that is true. But that definition is not the everyday definition of side-effect. Repeating and explaining one definition doesn't make the other go away. 1. To say that the C printf function has the side-effect of printing to the screen - that's true. 2. To say that the C printf function has no side-effects because it works correctly - the only effects are intentional - that's also true. Two definitions of side-effect. The definition used for case 2 is a lot older than the definition used for case 1, and remains valid. It's the normal usage that most people are familiar with everywhere - not just in programming and computer science. I haven't failed to understand either definition - I simply accept that both are valid. Natural language is ambiguous - sad fact of life. Using similar mixed definitions to conclude that every C program is full of bugs (basically equating intentional effects with side-effects, then equating side-effects with unintentional bugs) is a fairly common thing in my experience, but it's a logical fallacy. If you aren't aware of the two definitions of side-effect, it's hard to get deal with that. Some people don't want anyone to figure out the fallacy - they like having this convenient way to attack C, irrespective of whether it's valid or not. Rare I think - mostly it's more confusion and memetics. But still, I'm convinced there's some sophistry in this. And I'm not the only person to think so, and to have reacted against that in the past. Extra sad - you don't need that fallacy to attack C. It's redundant. C is quite happy to demonstrate its many failings. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
On 29/12/2011 21:51, Jerzy Karczmarczuk wrote: Steve Horne : I only meant that there's random number handling support in the Haskell library and, and least judging by type signatures, it's pure functional code with no hint of the IO monad. Look well at those functions, please. Challenge accepted. Some code (intended to be loaded into GHCi and played with) that I once wrote when doing the ninety-nine problems thing (the one that doesn't have ninety-nine problems - originally based on a Prolog tutorial IIRC)... -- Randomly select the specified number of items from the list -- -- Usage in GHCi... -- -- import System.Random -- randSelect this is a list 5 (mkStdGen 9877087) -- -- This will give the same results each time (for the same seed given to mkStdGen) -- -- randSelect' does the real work, but needs to know the length of the remaining -- list and doesn't do error checks (for efficiency reasons). module P23 (randSelect) where import System.Random randSelect' :: RandomGen g = [x] - Int - Int - g - ([x], g) randSelect' [] n l g = ([], g) -- n and l should be == 0, but no need for run-time check -- optimisation cases - no choice left randSelect' xs n l g | (n == l) = (xs, g) | (n == 0) = ([], g) randSelect' (x:xs) n l g = let xsLen = (l - 1) (rnd, g') = randomR (0, xsLen) g (keep, n') = if (rnd n) then (True, (n-1)) else (False, n) (xs', g'') = randSelect' xs n' xsLen g' in ((if keep then (x:xs') else xs'), g'') randSelect :: RandomGen g = [x] - Int - g - ([x], g) randSelect xs n g = let len = (length xs) in if (n len) then error Not enough items in the list! else randSelect' xs n len g I see no IO monad anywhere in there. Of course I'm cheating - providing a constant seed at runtime. It's a bit like the classic chosen by a throw of a fair die joke in a way. But the functions I'm using are pure. I don't claim to know every Haskell library function, of course. If there's further functions for that, all well and good - but there's still a perfectly adequate pure functional subset. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 2011-12-29 15:23, Gregg Reynolds wrote: On Dec 29, 2011, at 1:21 PM, Heinrich Apfelmus wrote: Why would IO Int be something special or mysterious? I'm pretty sure IO is non-deterministic, non-computable, etc. In other words not the same as computation. It's an ordinary value like everything else; it's on the same footing as [Char], Maybe Int, Int - String, Bool, and so on. I see no difference between the list [1,2,3] :: [Int] and the action pick a random number between 1 and 6 :: IO Int . We'll have to agree to disagree - I see a fundamental difference. You're misunderstanding the location of disagreement. We all know very well how IO Int is special. The example pick a random number between 1 and 6 was unfortunate. I hope fmap read getLine :: IO Int serves better. The Haskell community says this expression indicates a value. To be clear, fmap read getline has the same value wherever it is written in a program or however many times it is called, or however many different Int values it produces. This definition of 'value' is at the heart of how we understand Haskell to be referentially transparent and pure. You can disagree, but if you hold that this expression does not have a value until at execution time it produces an Int, then your unconventional terminology will lead to confusion. So what is the benefit of using Haskell? Isn't fmap read getline just as problematic as the C function gets() regardless of whether you call it pure? In Haskell, the type of fmap read getline prevents it from being used in arbitrary parts of the program, so the programmer or compiler can use the type to know whether a function is performing I/O or other effects. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Text.Regex.Base throws exceptions with makeRegexOptsM
Hi folks, I'm using Text.Regex.Base with the TDFA and PCRE backends. I want to compile regular expressions first and make sure the patterns were actually valid, so I used makeRegexOptsM, which indicates a bad regular expression by calling fail. That allows you to use makeRegexOptsM with Maybe or with (Either String) (assuming that Either String is an instance of Monad, which of course is defined in Control.Monad.Error.) Doing this with Maybe Regex works like it should--bad pattern gives you a Nothing. But if you want to see the error message by using Either String, an exception gets thrown with the bad pattern, rather than getting a Left String. Why is this? Seems like an odd bug somewhere. I am a Haskell novice, but I looked at the code for Text.Regex.Base and for the TDFA and PCRE backends and there's nothing in there to suggest this kind of behavior--it should work with Either String. The attached code snippet demonstrates the problem. I'm on GHC 7.0.3 (though I also got the problem with 6.12.3) and regex-base-0.93.2 and regex-tdfa-1.1.8 and regex-pcre-0.94.2. Thanks very much for any tips or ideas. --Omari module Main where import Text.Regex.Base.RegexLike import Text.Regex.TDFA.String import Control.Monad.Error badPattern = [unclosed brace main = do let maybeRegex = makeRegexOptsM defaultCompOpt defaultExecOpt badPattern :: Maybe Regex -- This outputs Bad, no regex, as expected putStrLn $ maybe Good regex (const Bad, no regex) maybeRegex let eitherRegex = makeRegexOptsM defaultCompOpt defaultExecOpt badPattern :: Either String Regex -- This throws an exception, why? The whole point of -- using makeRegexOptsM is to not have exceptions. putStrLn $ either show (const Good regex) eitherRegex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Sorry to cut most of this out, but I'm trying to focus on the central point here. On Thu, 2011-12-29 at 22:01 +, Steve Horne wrote: In pure functional terms, the result should be equivalent to a fully evaluated value - but putStrLn isn't pure. It cannot be fully evaluated until run-time. And here it is, I think. You're insisting on viewing the performing of some effect as part of the evaluation of an expression, even though the language is explicitly and intentionally designed not to conflate those two ideas. Effects do not happen as a side-effect of evaluating expressions. Instead they happen because you define the symbol 'main' to be the effect that you want to perform, and then set the runtime system to work on performing it by running your program. Evaluation and effects are just not the same thing, and it makes no sense to say something isn't evaluated just because the effect it describes haven't been performed. It's exactly that distinction -- the refusal to conflate evaluation with performing effects -- that is referred to when Haskell is called a pure language. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Steve Horne wrote: I haven't seen this view explicitly articulated anywhere before See Conal Elliott's blog post The C language is purely functionalhttp://conal.net/blog/posts/the-c-language-is-purely-functional . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell /Random generators
Steve Horne : Some code (intended to be loaded into GHCi and played with) -- import System.Random -- randSelect this is a list 5 (mkStdGen 9877087) -- ... module P23 (randSelect) where -- ... randSelect' (x:xs) n l g = let xsLen = (l - 1) (rnd, g') = randomR (0, xsLen) g -- ... I see no IO monad anywhere in there. Of course I'm cheating - providing a constant seed at runtime. The last remark is irrelevant. Normally the seed IS constant, injected once, then updated by the generator iself. I don't know what you are trying to prove. That you don't need monads? Everybody knows this. Look at your own code. In randSelect' you write (rnd, g') = randomR (0, xsLen) g **You don't need monads, because you do your own sequencing and propagating the seed*, g - g'.* Your library internal: randomR :: RandomGen g = (a, a) - g - (a, g) does the same thing, choosing a number within a range, *and propagating g*. (I call it a seed, but it is a Int seed wrapped within a StdGen...) OK, I repeat once more... Monads are useful ONLY to iterate the primitive generator, hiding the seed. The generator itself (the algorithm of Pierre L'Ecuyer or any other comparable) is obviously pure. The monadisation was a design choice of Lennart Augustson, who decided to dump (hide) (StdGen s1 s2) inside an IORef, but nobody is obliged to use it. There are alternatives, such as generating first an infinite random stream, or your own manufacture. So, OK, you have your pure generator. I explain why your question is based on some misunderstanding. All this has NOTHING to do whatsoever with the question of purity or not. Haskell code is pure if you propagate the StdGen yourself, it remains pure when the sequencing uses (=). Here this mythical World which visibly frightens you, reduces to two integers32. Either they propagate in your code, or through the iterate functional, or through the bind. In the last case it is hidden, so it may change, since only ONE instance is accessible. [[Actually, one exercice I gave to my students was to implement an iterable random generator using the State monad. Of course, there were numerous suicides, and the survivors have been isolated in the Arkham asylum, but the world is still there]]. Clean uses unique access variables for the same purpose, and the Clean users usually live normally with them. Jerzy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.Regex.Base throws exceptions with makeRegexOptsM
On Thursday 29 December 2011, 23:52:46, Omari Norman wrote: Hi folks, I'm using Text.Regex.Base with the TDFA and PCRE backends. I want to compile regular expressions first and make sure the patterns were actually valid, so I used makeRegexOptsM, which indicates a bad regular expression by calling fail. That allows you to use makeRegexOptsM with Maybe or with (Either String) (assuming that Either String is an instance of Monad, which of course is defined in Control.Monad.Error.) Doing this with Maybe Regex works like it should--bad pattern gives you a Nothing. But if you want to see the error message by using Either String, an exception gets thrown with the bad pattern, rather than getting a Left String. Why is this? The cause is that a pattern-match failure in a do-block or equivalent causes the Monad's 'fail' method to be invoked. For Maybe, we have fail _ = Nothing For Either, there used to be instance Error e = Monad (Either e) where ... fail s = Left (strMsg s) in mtl's Control.Monad.error, and all was fine if one used the regex functions with e.g. (Either String) as the Monad. Recently, however, it was decided to have instance Monad (Either e) where ... fail s = error s -- not explicitly, but by Monad's default method in Control.Monad.Instances. So now, if you have a pattern-match failure using (Either String), you don't get a nice 'Left message' but an error. So why was it decided to have that change? 'fail' doesn't properly belong in the Monad class, it was added for the purpose of dealing with pattern-match failures, but most monads can't do anything better than abort with an error in such cases. 'fail' is widely considered a wart. On the other hand, the restriction to Either's first parameter to belong to the Error class is artificial, mathematically, (Either e) is a Monad for every type e. And (Either e) has use-cases as a Monad for types which aren't Error members. So the general consensus was that it was better to get rid of the arbitrary (Error e) restriction. Now, what can you do to get the equivalent of the old (Either String)? Use 'ErrorT String Identity'. It's a bit more cumbersome to get at the result, foo = runidentity . runErrorT $ bar but it's clean. Seems like an odd bug somewhere. A change in behaviour that was accepted as the price of fixing what was widely considered a mistake. I am a Haskell novice, but I looked at the code for Text.Regex.Base and for the TDFA and PCRE backends and there's nothing in there to suggest this kind of behavior--it should work with Either String. It used to. The attached code snippet demonstrates the problem. I'm on GHC 7.0.3 (though I also got the problem with 6.12.3) and regex-base-0.93.2 and regex-tdfa-1.1.8 and regex-pcre-0.94.2. Thanks very much for any tips or ideas. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 30/12/2011 00:16, Sebastien Zany wrote: Steve Horne wrote: I haven't seen this view explicitly articulated anywhere before See Conal Elliott's blog post The C language is purely functional http://conal.net/blog/posts/the-c-language-is-purely-functional. Thanks - yes, that's basically the same point. More concise - so clearer, but not going into all the same issues - but still the same theme. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 29/12/2011 23:30, Chris Smith wrote: Sorry to cut most of this out, but I'm trying to focus on the central point here. On Thu, 2011-12-29 at 22:01 +, Steve Horne wrote: In pure functional terms, the result should be equivalent to a fully evaluated value - but putStrLn isn't pure. It cannot be fully evaluated until run-time. And here it is, I think. You're insisting on viewing the performing of some effect as part of the evaluation of an expression, even though the language is explicitly and intentionally designed not to conflate those two ideas. Effects do not happen as a side-effect of evaluating expressions. Instead they happen because you define the symbol 'main' to be the effect that you want to perform, and then set the runtime system to work on performing it by running your program. So, to resurrect an example from earlier... f :: Int - IO Int f = getAnIntFromTheUser = \i - return (i+1) Are you claiming that the expression (i+1) is evaluated without knowing the value of i? If not, at run-time your Haskell evaluates those expressions that couldn't be fully evaluated at compile-time. If you do, we're back to my original model. The value returned by main at compile-time is an AST-like structure wrapped in an IO monad instance. The AST nodes are partially evaluated functions, but since they can't be evaluated in a sense that knows the precise result of that + operator, we say this unevaluated function can be treated as a value in itself - let's compose bigger ASTs out of smaller ones. In that model, the 'i' above - the argument to the lambda - never gets an Int value because it's really just a placeholder for tracking the intended flow of data that won't actually flow until run-time. But that AST is just a translated description of the same program. It isn't the end result - it's just an intermediate step along the road to being able to run the thing. The unevaluated function is just falling back on returning a representation of its unevaluated self. That model is still compiled to executable code. That executable code, when run, still interacts with it's environment. That is as much an aspect of what Haskell defines as the functional core. Switching mental models doesn't change the logic any more than switching number bases. They are different descriptions of the same thing. The models are superficially different, but the logic is equivalent. It really doesn't matter whether you call something an AST node or an unevaluated function. An AST node can represent an unevaluated function. An unevaluated function can be implemented as a closure - which is just a collection of data, the same as an AST node. The two things are really both *still* the exact same thing. Even when it's translated to binary executable code, it is *still* the unevaluated function - right up until it gets executed (and in the same moment, evaluated). Either way, at run-time, Haskell is impure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
Le 30/12/2011 01:44, Steve Horne a écrit : Switching mental models doesn't change the logic any more than switching number bases. Especially when your mental model operates with Dybbuks which do horrible things behind your back... If this is your vision of logic, it is a peculiar one. Either way, at run-time, Haskell is impure. Most people here, some VERY knowledgeable, do not agree with you. /Errare humanum est, perseverare diabolicum/. Either way, since you insist to prove that you DON'T WANT to understand other people view, I wish you good luck. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
I wrote that post to point out the fuzziness that fuels many discussion threads like this one. See also http://conal.net/blog/posts/notions-of-purity-in-haskell/ and the comments. I almost never find value in discussion about whether language X is functional, pure, or even referentially transparent, mainly because those terms are used so imprecisely. In the notions-of-purity post, I suggest another framing, as whether or not a language and/or collection of data types is/are denotative, to use Peter Landin's recommended replacement for functional, declarative, etc. I included some quotes and a link in that post. so people can track down what denotative means. In my understanding, Haskell-with-IO is not denotative, simply because we do not have a (precise/mathematical) model for IO. And this lack is by design, as explained in the toxic avenger remarks in a comment on that post. I often hear explanations of what IO means (world-passing etc), but I don't hear any consistent with Haskell's actual IO, which includes nondeterministic concurrency. Perhaps the difficulties could be addressed, but I doubt it, and I haven't seen claims pursued far enough to find out. - Conal On Thu, Dec 29, 2011 at 4:42 PM, Steve Horne sh006d3...@blueyonder.co.ukwrote: On 30/12/2011 00:16, Sebastien Zany wrote: Steve Horne wrote: I haven't seen this view explicitly articulated anywhere before See Conal Elliott's blog post The C language is purely functionalhttp://conal.net/blog/posts/the-c-language-is-purely-functional . Thanks - yes, that's basically the same point. More concise - so clearer, but not going into all the same issues - but still the same theme. ___ 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] On the purity of Haskell /Random generators
On 30/12/2011 00:22, Jerzy Karczmarczuk wrote: Steve Horne : Some code (intended to be loaded into GHCi and played with) -- import System.Random -- randSelect this is a list 5 (mkStdGen 9877087) -- ... module P23 (randSelect) where -- ... randSelect' (x:xs) n l g = let xsLen = (l - 1) (rnd, g') = randomR (0, xsLen) g -- ... I see no IO monad anywhere in there. Of course I'm cheating - providing a constant seed at runtime. The last remark is irrelevant. Normally the seed IS constant, injected once, then updated by the generator iself. I don't know what you are trying to prove. I don't know why you think I'm trying to prove something here. Earlier, I mentioned that Haskell provides pure functional random number support in the library - as part of going off on a tangent and, as it happens, of making a mistake. I specifically said something like with no mention of the IO monad with respect to type signatures. You said Look well at those functions, please. I accepted your challenge. I looked well. I still say that Haskell provides pure functional random number support in the library. My last remark was there basically because of the earlier mistake - acknowledging that I've bypassed the whole issue of where the seed comes from, which may for all I know be supported by a library IO action, and which would be relevant given how this randomness thread started. That was my first mistake in this randomness thread - another mistake I made was saying unsafePerformIO might reasonably be used to sneak in entropy. Basically, I replied to your challenge - nothing more. I really don't even care much about random numbers - that's why my easiest reference was from back when I was doing those tutorials. There is no deep point here unless you're making one I haven't understood yet. As for whether or not Haskell is pure - this randomness thread isn't relevant to that any more. If you see my reference to purity as a weasel way of insinuating that there's also impurity in Haskell - I don't need to insinuate that, I've openly stated my view and explained my reasoning as well as I'm able. What point is there in being a cowardly weasel if you also paint a bullseye on your head and shout Here I am!? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, 2011-12-30 at 00:44 +, Steve Horne wrote: So, to resurrect an example from earlier... f :: Int - IO Int f = getAnIntFromTheUser = \i - return (i+1) Did you mean f :: IO Int ? If not, then I perhaps don't understand your example, and your monad is not IO. I'll continue assuming the former. Are you claiming that the expression (i+1) is evaluated without knowing the value of i? I'm not sure what you mean by evaluated here. I'd say it's in normal form, but it has free variables so it's not even meaningful by itself; it doesn't have a value in the first place. On the other hand, the larger expression, \i - return (i+1), is closed *and* effectively in normal form, so yes, I'd definitely say it is evaluated so far as that word has any meaning at all. If not, at run-time your Haskell evaluates those expressions that couldn't be fully evaluated at compile-time. I certainly agree that the GHC runtime system, and any other Haskell implementation's runtime system as well, evaluates expressions (some representation of them anyway), and does lots of destructive updates to boot. This isn't at issue. What is at issue is whether to shoehorn those effects into the language semantics as a side-effect of evaluation (or equivalently, force evaluation of expressions to be seen as an effect -- when you only allow for one of these concepts, it's a silly semantic game as to which name you call it by), or to treat effects as semantically first-class concepts in their own right, different from the simplification of expressions into values. If you do, we're back to my original model. The value returned by main at compile-time is an AST-like structure wrapped in an IO monad instance. Here you're introducing implementation detail here that's rather irrelevant to the semantics of the language. Who knows whether compiler and the runtime implementation build data structures corresponding to an AST and run a reduction system on them, or use some other mechanism. One could build implementations that do it many different ways. In fact, what most will do is generate machine code that directly performs the desired effects and use closures with pointers to the generated machine code. But that's all beside the point. If you need to know how your compiler is implemented to answer questions about language semantics, you've failed already. Purity isn't about the RTS implementation, which is of course plenty effectful and involves lots of destructive updates. It's about the language semantics. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 2011-12-29 19:44, Steve Horne wrote: [Interaction with its environment] is as much an aspect of what Haskell defines as the functional core. Switching mental models doesn't change the logic But it does. Other languages do not support the distinction between pure functions and I/O effects. In those languages a function call is what triggers I/O. Haskell uses a different set of types for I/O. It does not use functions for this. The distinction between pure functions and impure code, supported by the language, is a valuable logical tool. You refer to the fact that as part of executing the Haskell program, it is translated into an AST that does not make that distinction. The effect getAnIntFromTheUser is translated into a function. The type of the function says nothing about whether the function has an effect. In that sense Haskell is impure, but so what? That doesn't take away the power of Haskell's distinction between pure functions and impure types, for reasoning about Haskell code. Either way, at run-time, Haskell is impure. No big deal. Who would want to use a language that you would call pure? Haskell has referential transparency. In Haskell, you have assurance that any function without IO in its type is as pure as the lambda calculus. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Level of Win32 GUI support in the Haskell platform
I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. Is this level of Win32 GUI coding supported? (other than by dealing with the FFI myself) Alternatively, should I be doing dialog-based coding and leaving Haskell to worry about message loops behind the scenes? Either way, is there an example I can use for reference? I have something along the lines of Petzolds Hello World in mind as the ideal (register a window class, handle the messages, paint some text), but anything that shows how to get a basic Win32 GUI app running in Haskell is fine. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 30/12/2011 01:37, Chris Smith wrote: On Fri, 2011-12-30 at 00:44 +, Steve Horne wrote: So, to resurrect an example from earlier... f :: Int - IO Int f = getAnIntFromTheUser= \i - return (i+1) Did you mean f :: IO Int ? If not, then I perhaps don't understand your example, and your monad is not IO. I'll continue assuming the former. Oops - I meant... f :: Int - IO Int f x = getAnIntFromTheUser = \i - return (i+x) Your version should be fine, only the lack of a parameter makes a superficial difference. I certainly agree that the GHC runtime system, and any other Haskell implementation's runtime system as well, evaluates expressions (some representation of them anyway), and does lots of destructive updates to boot. This isn't at issue. What is at issue is whether to shoehorn those effects into the language semantics as a side-effect of evaluation (or equivalently, force evaluation of expressions to be seen as an effect -- when you only allow for one of these concepts, it's a silly semantic game as to which name you call it by), or to treat effects as semantically first-class concepts in their own right, different from the simplification of expressions into values. Well, we're playing a semantic game anyway. Treating effects as first-class concepts in themselves is fine, but IMO doesn't make Haskell pure. If you do, we're back to my original model. The value returned by main at compile-time is an AST-like structure wrapped in an IO monad instance. Here you're introducing implementation detail here that's rather irrelevant to the semantics of the language. Think of it as an analogy - using the terminology of compiler design. I might describe arithmetic in terms of an abacus too - it doesn't mean I'd only get those results if I used an abacus. The implementation details don't matter - the behaviour of the program does. Purity isn't about the RTS implementation, which is of course plenty effectful and involves lots of destructive updates. It's about the language semantics. And the semantics of primitive IO actions *include* the run-time effects - those semantics are defined in the Haskell Report. For example... Computation hGetChar hdl reads a character from the file or channel managed by hdl. If you have another meaning in mind for the word semantics, well that's fine. As already discussed with side effects, natural language is sadly ambiguous. It can be confusing, but it doesn't change the facts or the logic. I don't know the first thing about denotational semantics, but I do know this - if you place run-time behaviour outside the scope of your model of program semantics, that's just a limitation of your model. It doesn't change anything WRT the program itself - it only limits the understanding you can derive using that particular model. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Overloaded Quotes for Template Haskell
What would it take to get an -XOverloadedQuotes flag of the same sort as the -XOverloadedStrings flag? I.e. [| ... |] would have type Quasi m = m Exp instead of Q Exp and any splices in that quotation expect the contents of that splice to have type m Exp. (Obviously, top level splices would still have type Q Exp otherwise the compiler wouldn't know how to evaluate the monad.) I ran into this problem when writing a Template Haskell program in which part of it operates in a StateT S Q a monad instead of the usual Q a monad. (The S type stores the state of a memoization table of code fragments already generated. Without it, the code would loop infinitely when processing certain recursive structures.) It is fairly easy to declare an instance of Quasi for StateT S Q, so in order to keep the code clean, I'd like to use quotations with splices in them (i.e. [| ... $( ... ) ... |] ) for expressing the generated code. However, quotations and splices are tied to the Q monad which means that as it is now I have to manually write LamE ... VarP ... VarE ... etc. instead of using the much nicer quotation syntax. Michael D. Adams mdmko...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: ekg-0.2 - Remote monitoring of processes
(I forgot to announce v0.1 so this is a combined announcement.) I'm proud to announce the ekg [1] library. The library lets you remotely monitor any running Haskell program, using your web browser or an automated monitoring program. The library lets you monitor garbage collector and memory usage statistics (similar to what's provided by +RTS -s, but live), but also lets you defined your own counters that you can update from within your program. For some more examples see: http://blog.johantibell.com/2011/12/remotely-monitor-any-haskell.html http://blog.johantibell.com/2011/12/more-monitoring-goodies.html 1. http://hackage.haskell.org/package/ekg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On 30/12/2011 01:40, Scott Turner wrote: On 2011-12-29 19:44, Steve Horne wrote: [Interaction with its environment] is as much an aspect of what Haskell defines as the functional core. Switching mental models doesn't change the logic But it does. Other languages do not support the distinction between pure functions and I/O effects. Agreed. I said basically the same thing right at the start. This doesn't change any logic, though. Either way, at run-time, Haskell is impure. No big deal. Who would want to use a language that you would call pure? Haskell has referential transparency. In Haskell, you have assurance that any function without IO in its type is as pure as the lambda calculus. Absolutely. In my original post, of course, I made my big implicit IORef parameter argument that says C too is referentially transparent, but I also pointed out another view of transparency - the politician who buries the relevant in a huge pile of the irrelevant is not being transparent - and pointed out that in Haskell you can have zero, one or many IORefs - you can focus in on what is relevant. I actually thought this point would make Haskell advocates happy, but no sign of that yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the purity of Haskell
On Fri, 2011-12-30 at 02:40 +, Steve Horne wrote: Well, we're playing a semantic game anyway. Treating effects as first-class concepts in themselves is fine, but IMO doesn't make Haskell pure. Okay, so if you agree that: (a) IO actions are perfectly good values in the Haskell sense. (b) They are first class (can passed to/returned from functions, etc.). (c) When used as plain values, they have no special semantics. (d) An IO action is no more a Haskell function than an Int is. (e) All effects of a Haskell program are produced by the runtime system performing the IO action called main (evaluating expressions lazily as needed to do so), and NOT as a side-effect of the evaluation of expressions. Then we are completely in agreement on everything except whether the word pure should apply to a programming language with those semantics. Certainly the rest of the Haskell community describes this arrangement, with effects being first-class values and performing those effects being something done by the runtime system completely separate from evaluating expressions, as Haskell being pure. You can choose your terminology. I don't know the first thing about denotational semantics, but I do know this - if you place run-time behaviour outside the scope of your model of program semantics, that's just a limitation of your model. It doesn't change anything WRT the program itself - it only limits the understanding you can derive using that particular model. The important bit about purity is that programs with I/O fit in to the pure model just fine! The pure model doesn't fully explain what the I/O actions do, of course, but crucially, they also do not BREAK the pure model. It's a separation of concerns: I can figure out the higher-level stuff, and when I need to know about the meaning of the values of specific hairy and opaque data types like IO actions, or some complex data structure, or whatever... well, then I can focus in and work out the meaning of that bit when the time comes up. The meanings of values in those specific complex types doesn't affect anything except those expressions that deal explicitly with that type. THAT is why it's so crucial that values of IO types are just ordinary values, not some kind of magic thing with special evaluation rules tailored to them. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Level of Win32 GUI support in the Haskell platform
On Fri, Dec 30, 2011 at 2:53 PM, Steve Horne sh006d3...@blueyonder.co.uk wrote: I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. Is this level of Win32 GUI coding supported? (other than by dealing with the FFI myself) I'd recommend using Gtk2hs (http://haskell.org/gtk2hs). It's well supported and your program will work on Mac Linux BSD to boot. Trying to grapple with Win32 APIs isn't exactly my idea of fun. :) ___ 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] IO typeclasses
Is there any particular reason IO functions in the standard libraries aren't grouped into type-classes? This might allow for: 1) Testing IO code without actual input and output. (I have done this on a small scale, but it presently involves much ugliness). 2) Redirecting output of a function that neglects to take a handle without a bunch of calls to dup. 3) Forwarding IO over a connection to a remote system, allowing code written to work locally to be applied remotely, or vice-versa. 4) Wrapping dangerous IO actions in additional sanity checks. Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO typeclasses
On Fri, Dec 30, 2011 at 4:47 PM, David Thomas davidleotho...@gmail.com wrote: Is there any particular reason IO functions in the standard libraries aren't grouped into type-classes? I'm guessing it's to stop the report from getting too complicated. If you want an IO abstraction, you can try HVIO: http://hackage.haskell.org/packages/archive/MissingH/latest/doc/html/System-IO-HVIO.html ___ 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] Level of Win32 GUI support in the Haskell platform
On Fri, 2011-12-30 at 01:53 +, Steve Horne wrote: I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. I see them in the Win32 package. http://hackage.haskell.org/packages/archive/Win32/2.2.1.0/doc/html/Graphics-Win32-Window.html#v:getMessage Alternatively, should I be doing dialog-based coding and leaving Haskell to worry about message loops behind the scenes? Various people recommend the gtk (aka Gtk2Hs) and wx packages for that. I've never been able to get wx to build, but gtk works fine. Others (mostly those using macs) report the opposite. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Level of Win32 GUI support in the Haskell platform
On 30/12/2011 03:43, Chris Wong wrote: On Fri, Dec 30, 2011 at 2:53 PM, Steve Horne sh006d3...@blueyonder.co.uk wrote: I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. Is this level of Win32 GUI coding supported? (other than by dealing with the FFI myself) I'd recommend using Gtk2hs (http://haskell.org/gtk2hs). It's well supported and your program will work on Mac Linux BSD to boot. Trying to grapple with Win32 APIs isn't exactly my idea of fun. :) I had dismissed GTK - I assumed getting it set up in Windows would be a bit painful, and figured I'd stick with whats in the Haskell Platform for the moment. I'm already familiar (though very rusty) with Win32 from C - it seemed like an easy if limited option. But I'll take a look at gtk2hs anyway. Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.Regex.Base throws exceptions with makeRegexOptsM
On Fri, Dec 30, 2011 at 01:24:02AM +0100, Daniel Fischer wrote: For Either, there used to be instance Error e = Monad (Either e) where ... fail s = Left (strMsg s) in mtl's Control.Monad.error, and all was fine if one used the regex functions with e.g. (Either String) as the Monad. Recently, however, it was decided to have instance Monad (Either e) where ... fail s = error s -- not explicitly, but by Monad's default method in Control.Monad.Instances. So now, if you have a pattern-match failure using (Either String), you don't get a nice 'Left message' but an error. Thanks so much, I would never have figured all this out. Spent a lot of time tonight rummaging through mtl and transformers and Control.Monad.Instances. Now, what can you do to get the equivalent of the old (Either String)? Use 'ErrorT String Identity'. This I tried. It turned out that it didn't work though and I had the same problem. I am guessing it is because my module has some imports at the top that are bringing the instances in Control.Monad.Instances into scope. Then it seems the Monad instance in Control.Monad.Instances (which is using the default fail, which calls error) is being used, rather than the instance from Control.Monad.Trans.Error. Only now do I really understand why orphan instances are bad: http://www.haskell.org/haskellwiki/Orphan_instance A simple fix for it all was to wrap Either in a newtype and then define a Monad instance for the newtype. --Omari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.Regex.Base throws exceptions with makeRegexOptsM
On Fri, Dec 30, 2011 at 1:24 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 29 December 2011, 23:52:46, Omari Norman wrote: [...] 'fail' doesn't properly belong in the Monad class, it was added for the purpose of dealing with pattern-match failures, but most monads can't do anything better than abort with an error in such cases. 'fail' is widely considered a wart. I thought I'd add my own reason why I don't like fail. Take these two functions, for example: test :: Maybe Int test = do (Right v) - Just (Left 1) return v test' :: Maybe Int test' = do let (Right v) = Left 1 return v The first returns Nothing. The second crashes with a pattern match failure. Why should a pattern failure cause a crash everywhere *except* a do binding? It makes no sense. It violates the principle of least surprise by behaving differently to every other occurrence of pattern matching in the whole language. As for custom failures, I'd recommend either Michael Snoyman's Failure class or MonadPlus, which were both designed for this sort of thing. But I'd stay away from using fail, since as Omari Norman said, it's a wart. ___ 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] Level of Win32 GUI support in the Haskell platform
On 30/12/2011 04:07, Chris Smith wrote: On Fri, 2011-12-30 at 01:53 +, Steve Horne wrote: I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. I see them in the Win32 package. http://hackage.haskell.org/packages/archive/Win32/2.2.1.0/doc/html/Graphics-Win32-Window.html#v:getMessage Ah - I didn't look in Graphics.Win32.Window because those functions don't relate to Windows. Clearly I gave up my search too easily - thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Level of Win32 GUI support in the Haskell platform
Hi, Steve Horne sh006d3592 at blueyonder.co.uk writes: I've been for functions like GetMessage, TranslateMessage and DispatchMessage in the Haskell Platform Win32 library - the usual message loop stuff - and not finding them. Hoogle says no results found. Haskell Platform includes the Win32 package which provides access to these functions. Hoogle doesn't index Windows-only packages, unfortunately. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type classes in Typing Haskell in Haskell
Hi, recently I tried the Typing Haskell in Haskell library. But I was wondering why this program type checks: -- plusMfun is standard '+': Num a = a - a - a test = let Just classEnv = ( addCoreClasses : addNumClasses ) initialEnv e = Ap ( Ap (Var +) (Lit $ LitStr 3)) (Lit $ LitStr 5) impl = (foo,[([],e)]) in putStrLn $ pretty $ runTI $ tiImpls classEnv [plusMfun] [impl] I was expecting some kind of typechecking error, because [Char] is no instance of Num. But I get this: ([isIn1 cNum (TAp tList tChar)], [foo :: Forall [] ([] := (TAp tList tChar))]) The predicate says that if [Char] would be in Num then the type of the expression would be [Char]. But actually [Char] isn't in Num. So, how do I provoke a type check error in this case? Thanks in advance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
