Re: [Haskell-cafe] License of CloudHaskell code write by Haskell language.
Hi, The version of Cloud Haskell you cite is a prototype. I recommend you use the 'distributed-process' package instead; it is licensed under BSD3. Edsko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I would like a clarification about Enumerators and Iteratees, please :)
Hi guys, I've started playing with Iteratee and Enumerators: very cool and addictive stuff. I have wrote this simple code: https://gist.github.com/3899017 In a nutshell, it gives back the number of occurences for a single char in case the argument passed from the command line is a single char, or the number of lines of the entire file. I've tried it first on a small file (~100MB) and then on a huge one (~3GB). As far as I understood Iteratee IO should be a smart way to do IO, avoiding to keep the entire file in memory; what I observe in the second case, instead, is a sort of memory leak. The memory grows and grows until the entire machine hangs. If I split the huge file in small chunks, memory comsumption is still high but the computation terminates and is fast. So my two questions: a) What am I missing? Should be memory used be constant? And how can I achieve this purpose? b) I'm using the package enumerator because as far as I can see is the most used. How does it compares with iteratee? Which of the two are more performant? Bye and thanks, A. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I would like a clarification about Enumerators and Iteratees, please :)
You have a space leak in countCharBS. Put a bang pattern on your accumulator. On Tue, Oct 16, 2012 at 2:46 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Hi guys, I've started playing with Iteratee and Enumerators: very cool and addictive stuff. I have wrote this simple code: https://gist.github.com/3899017 In a nutshell, it gives back the number of occurences for a single char in case the argument passed from the command line is a single char, or the number of lines of the entire file. I've tried it first on a small file (~100MB) and then on a huge one (~3GB). As far as I understood Iteratee IO should be a smart way to do IO, avoiding to keep the entire file in memory; what I observe in the second case, instead, is a sort of memory leak. The memory grows and grows until the entire machine hangs. If I split the huge file in small chunks, memory comsumption is still high but the computation terminates and is fast. So my two questions: a) What am I missing? Should be memory used be constant? And how can I achieve this purpose? b) I'm using the package enumerator because as far as I can see is the most used. How does it compares with iteratee? Which of the two are more performant? Bye and thanks, A. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote: I'm uncertain where this, compositional means written as the composition of functions, thing started. But it is not what I, and I'm sure any others mean by the term, compositional. You're right. It's a rather recent, as far as I can tell, overloading of the word that I inadvertently picked up. The meaning of this overloading, at least as I understand and intended it, is that it forms a category. I will try to avoid this use of the word in the future. For three, I can't for the life of me think of how anyone would write (=) as a primitive operation _except_ for writing (=) and then '(f = g) x = f x = g'. The function cannot be inspected to get the result except by applying it. This is a good point. I'd be down with putting join in the class, but that tends to not be terribly important for most cases, either. Join is not the most important, but I do think it's often easier to define than bind. I often find myself implementing bind by explicitly using join. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess j...@kitenet.net wrote: Michael Snoyman wrote: I think I have a misunderstanding of how forkProcess should be working. Ultimately this relates to some bugs in the development version of keter, but I've found some behavior in a simple test program which I wouldn't have expected either, which may or may not be related. With the program at the end of this email, I would expect that, once per second, I would get a message printed from each forkIO'd green thread, the forked process, and the master process. And if I spawn 8 or less child threads that's precisely what happens. However, as soon as I up that number to 9, the child process is never run. The process is, however, created, as can be confirmed by looking at the process table. This only occurs when using the multithreaded runtime. In other words, compiling with ghc --make test.hs seems to always produce the expected output, whereas ghc --make -threaded test.hs causes the behavior described above. Having looked through the code for the process package a bit, my initial guess is that this is being caused by a signal being sent to the child process, but I'm not familiar enough with the inner workings to confirm or disprove this guess. If anyone has any ideas on this, I'd appreciate it. While I'm not reproducing that behavior here with your test case and 7.4.1, I recently converted a large program to use -threaded (because I needed to use yesod in it, actually :), and had large quantities of pain involving forkProcess. It seemed to come down to this easily overlooked note in the docs: forkProcess comes with a giant warning: since any other running threads are not copied into the child process, it's easy to go wrong: e.g. by accessing some shared resource that was held by another thread in the parent. In my experience, forkProcess often behaves incomprehensibly (to me) with -threaded, typically resulting in a forked process hanging, and quite often only some small percentage of the time, which makes it really hard to track down and try to diagnose what thunk might not be getting forced until after the fork, or whatever. I did some analysis and produced a test case for problems caused by use of forkProcess in parts of MissingH, here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681621 My understanding is that System.Process avoids these problems by doing all the setup around forking a command in C code. I've banished forkProcess from my code base entirely, except for a double fork I need to daemonize, and I don't even trust that call. :/ Well, I tried switching my code to forking/execing from C in a very similar manner to the process package, and it seems to work. Thanks for the input everyone! Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
Le Tue, 16 Oct 2012 07:35:34 +0530, damodar kulkarni kdamodar2...@gmail.com a écrit : @Jake In my opinion, this is not as nice as the do-notation version, but at least it's compositional: That's an important point you have made, as Haskellers value code composition so much. If code composition is the holy grail, why not encourage the monadic code, too, to be compositional? Nicety can wait; some syntax sugar might take care of it. And as you have pointed out, arrows make a superior choice in this regard, but they are rather newer to monads. @ AUGER Cédric It would be rather awful to expand each of your Kleisli arrows with const as you said. The const is required in this example because we are dealing with getLine (as getLine can return different strings at different times without taking any argument). Again, some syntactic sugar would have taken care of this const thing. Correct me if I am wrong. We were not dealing with getLine in particular. The point was about knowing if = could be defined in terms of =. The const is necessary for the general case. So I think that an implicit question was why wouldn't we have: class Monad m where return :: a - m a kleisli :: (a - m b) - (b - m c) - (a - m c) bind = \ x f - ((const x) = f) () join = id=id :: (m (m a) - m a) (Sorry, I do not remember the correct Haskell syntax, I am a beginner, but I do not have touched the language for some time…) That is bind would have a default construction (like join has got its one now). The definition of join would become rather nice this way ^^ Not redefining the join and bind function would lead to expand them with \ x f - (const x) = f and id=id, that is what I meant, and found it awful for bind. Of course I do not say that Kleisli is a bad idea. I even think it is better to use it when you want composition, or you want to do the initial given example (readString = putString, or something like that, I do not really remember). But I do not think defining Monads from Kleisli (or T-algebras, for the other adjunction construction) would be very nice. On the other hand, I guess that the class Monad could contain the definition of Kleisli arrows. But as we have instances ArrowApply a = Monad (ArrowMonad a) and Monad m = Arrow (Kleisli m), I do not think we lack some functionnality. and thanks for responses. Damodar On Mon, Oct 15, 2012 at 9:09 PM, Jake McArthur jake.mcart...@gmail.comwrote: On Mon, Oct 15, 2012 at 11:33 AM, Jake McArthur jake.mcart...@gmail.com wrote: On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez e...@ertes.de wrote: Try to express do x - getLine y - getLine print (x, y) using only Kleisli composition (without cheating). My previous answer didn't do the Kleisli style much justice. It could look a bit nicer with more Arrow-style combinators: f = g = runKleisli $ Kleisli f Kleisli g print = const getLine = const getLine $ () ___ 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] Why Kleisli composition is not in the Monad signature?
Le Tue, 16 Oct 2012 09:51:29 -0400, Jake McArthur jake.mcart...@gmail.com a écrit : On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote: I'd be down with putting join in the class, but that tends to not be terribly important for most cases, either. Join is not the most important, but I do think it's often easier to define than bind. I often find myself implementing bind by explicitly using join. join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem). As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law). As often some points it out, Haskellers are not very right in their definition of Monad, not because of the bind vs join (in fact in a Monad either of them can be defined from the other one), but because of the functor status of a Monad. A monad, should always be a functor (at least to fit its mathematical definition). And this problem with the functor has probably lead to the use of bind (which is polymorphic in two type variables) rather than join (which has only one type variable, and thus is simpler). The problem, is that when 'm' is a Haskell Monad which does not belong to the Functor class, we cannot define 'bind' in general from 'join'. That is in the context where you have: return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) x:m a f:a → (m b) you cannot define some term of type 'm b', since you would need to use at the end, either 'f' (and you would require to produce a 'a' which would be impossible), or 'return' (and you would need to produce a 'b', which is impossible), or 'join' (and you would need to produce a 'm (m b)', and recursively for that you cannot use return which would make you go back to define a 'm b' term) For that, you need the 'fmap' operation of the functor. return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) fmap:∀ a b. (a→b) → ((m a)→(m b)) x:m a f:a → (m b) in this context defining a term of type 'm b' is feasible (join (fmap f x)), so that you can express bind = \ x f - join (fmap f x). To sum up, mathematical monads are defined from 'return' and 'join' as a mathematical monad is always a functor (so 'fmap' is defined, and 'bind', which is more complex than 'join' can be defined from 'join' and 'fmap'). Haskell does not use a very good definition for their monads, as they may not be instance of the Functor class (although most of them can easily be defined as such), and without this 'fmap', 'join' and 'return' would be pretty useless, as you wouldn't be able to move from a type 'm a' to a type 'm b'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
Although I agree that Functor should be a superclass of Monad, the two methods of the Monad typeclass _are_ sufficient to make any instance into a Functor in a mechanical/automatic way. The language may not know it, but return/bind is equivalent in power to fmap/return/join. Apart from bind being easier to use for the things we typically do with monads in programs, using bind is actually more succinct in that it doesn't require three primitive operations. I'm not saying bind is a better primitive than join/fmap, but mathematicians do it this way, therefore it's better doesn't seem like a particularly convincing argument either. And for a more philosophical question, is something not a functor just because we don't have a Functor instance for it? If we agree that the Monad class (with no Functor superclass) does implicitly form a Functor with liftM, then I don't really see what the problem is, apart from the inconvenience of not being able to use fmap. On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote: Le Tue, 16 Oct 2012 09:51:29 -0400, Jake McArthur jake.mcart...@gmail.com a écrit : On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote: I'd be down with putting join in the class, but that tends to not be terribly important for most cases, either. Join is not the most important, but I do think it's often easier to define than bind. I often find myself implementing bind by explicitly using join. join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem). As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law). As often some points it out, Haskellers are not very right in their definition of Monad, not because of the bind vs join (in fact in a Monad either of them can be defined from the other one), but because of the functor status of a Monad. A monad, should always be a functor (at least to fit its mathematical definition). And this problem with the functor has probably lead to the use of bind (which is polymorphic in two type variables) rather than join (which has only one type variable, and thus is simpler). The problem, is that when 'm' is a Haskell Monad which does not belong to the Functor class, we cannot define 'bind' in general from 'join'. That is in the context where you have: return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) x:m a f:a → (m b) you cannot define some term of type 'm b', since you would need to use at the end, either 'f' (and you would require to produce a 'a' which would be impossible), or 'return' (and you would need to produce a 'b', which is impossible), or 'join' (and you would need to produce a 'm (m b)', and recursively for that you cannot use return which would make you go back to define a 'm b' term) For that, you need the 'fmap' operation of the functor. return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) fmap:∀ a b. (a→b) → ((m a)→(m b)) x:m a f:a → (m b) in this context defining a term of type 'm b' is feasible (join (fmap f x)), so that you can express bind = \ x f - join (fmap f x). To sum up, mathematical monads are defined from 'return' and 'join' as a mathematical monad is always a functor (so 'fmap' is defined, and 'bind', which is more complex than 'join' can be defined from 'join' and 'fmap'). Haskell does not use a very good definition for their monads, as they may not be instance of the Functor class (although most of them can easily be defined as such), and without this 'fmap', 'join' and 'return' would be pretty useless, as you wouldn't be able to move from a type 'm a' to a type 'm b'. ___ 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] Why Kleisli composition is not in the Monad signature?
Le Tue, 16 Oct 2012 11:22:08 -0400, Daniel Peebles pumpkin...@gmail.com a écrit : Although I agree that Functor should be a superclass of Monad, the two methods of the Monad typeclass _are_ sufficient to make any instance into a Functor in a mechanical/automatic way. The language may not know it, but return/bind is equivalent in power to fmap/return/join. Apart from bind being easier to use for the things we typically do with monads in programs, using bind is actually more succinct in that it doesn't require three primitive operations. Succintness is not the point for me. For me, the point is primitiveness/elementaryness. For instance bind has type m a → (a → m b) → m b [2 type variables, one functionnal argument, one 'scalar' argument] whereas join has type m (m a) → m a [1 type variable, one 'scalar' argument] and fmap has type (a → b) → (m a → m b) [2 type variables, one functionnal argument, one 'scalar' argument] So here, 'join' is definitely more simple than 'bind'. 'fmap' and 'bind' are about same complexity (although we can consider 'fmap' slightly simpler as its functionnal argument has type 'a→b' and not 'a→m b'). Having one single powerfull function is often overkill, and you will probably require more simple functions which you will get by feeding your big function with dummy ones (such as 'id' or 'const'), and you may lose some efficiency. I do not know if you have studied the S, K, I system of combinators. It is a system which is equivalent to λ-calculus if I well remember. There are supercombinators system which requires only one combinator, but almost nobody bother with them as they lead to define too ugly terms. I'm not saying bind is a better primitive than join/fmap, but mathematicians do it this way, therefore it's better doesn't seem like a particularly convincing argument either. I never said that, just that the Monad name is somehow not very appropriate. And for a more philosophical question, is something not a functor just because we don't have a Functor instance for it? If we agree that the Monad class (with no Functor superclass) does implicitly form a Functor with liftM, then I don't really see what the problem is, apart from the inconvenience of not being able to use fmap. I forgot about the liftM, so ok, the name is not that inapropriate, although you have to wrap your stuff in the WrappedMonad… On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote: Le Tue, 16 Oct 2012 09:51:29 -0400, Jake McArthur jake.mcart...@gmail.com a écrit : On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote: I'd be down with putting join in the class, but that tends to not be terribly important for most cases, either. Join is not the most important, but I do think it's often easier to define than bind. I often find myself implementing bind by explicitly using join. join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem). As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law). As often some points it out, Haskellers are not very right in their definition of Monad, not because of the bind vs join (in fact in a Monad either of them can be defined from the other one), but because of the functor status of a Monad. A monad, should always be a functor (at least to fit its mathematical definition). And this problem with the functor has probably lead to the use of bind (which is polymorphic in two type variables) rather than join (which has only one type variable, and thus is simpler). The problem, is that when 'm' is a Haskell Monad which does not belong to the Functor class, we cannot define 'bind' in general from 'join'. That is in the context where you have: return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) x:m a f:a → (m b) you cannot define some term of type 'm b', since you would need to use at the end, either 'f' (and you would require to produce a 'a' which would be impossible), or 'return' (and you would need to produce a 'b', which is impossible), or 'join' (and you would need to produce a 'm (m b)', and recursively for that you cannot use return which would make you go back to define a 'm b' term) For that, you need the 'fmap' operation of the functor. return:∀ a. a → (m a) join:∀ a. (m (m a)) → (m a) fmap:∀ a b. (a→b) → ((m a)→(m b)) x:m a f:a → (m b) in this context defining a term of type 'm b' is feasible (join (fmap f x)), so that you can express bind = \ x f - join (fmap f x). To sum up, mathematical monads are defined from 'return' and 'join' as a mathematical monad is
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote: join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem). As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law). This is the way it's typically presented. Can you demonstrate that it is the most important presentation? I'd urge caution in doing so, too. For instance, there is a paper, Monads Need Not Be Endofunctors, that describes a generalization of monads to monads relative to another functor. And there, bind is necessarily primary, because join isn't even well typed. I don't think it's written by mathematicians per se (rather, computer scientists/type theorists). But mathematicians have their own particular interests that affect the way they frame things, and that doesn't mean those ways are better for everyone. As often some points it out, Haskellers are not very right in their definition of Monad, not because of the bind vs join (in fact in a Monad either of them can be defined from the other one), but because of the functor status of a Monad. A monad, should always be a functor (at least to fit its mathematical definition). And this problem with the functor has probably lead to the use of bind (which is polymorphic in two type variables) rather than join (which has only one type variable, and thus is simpler). The problem, is that when 'm' is a Haskell Monad which does not belong to the Functor class, we cannot define 'bind' in general from 'join'. I don't think Functor being a superclass of Monad would make much difference. For instance, Applicative is properly a subclass of Functor, but we don't use the minimal definition that cannot reproduce fmap on its own: class Functor f = LaxMonoidal f where unit :: f () pair :: f a - f b - f (a, b) Instead we use a formulation that subsumes fmap: fmap f x = pure f * x Because those primitives are what we actually want to use, and it's more efficient to implement those directly than to go through some set of fully orthogonal combinators purely for the sake of mathematical purity. And this goes for Monad, as well. For most of the monads in Haskell, the definition of join looks exactly like a definition of (= id), and it's not very arduous to extend that to (= f). But if we do define join, then we must recover (=) by traversing twice; once for map and once for join. There are some examples where join can be implemented more efficiently than bind, but I don't actually know of any Haskell Monads for which this is the case. And as I mentioned earlier, despite many Haskell folks often not digging into monads as done by mathematicians much (and that's fine), (=) does correspond to a nice operation: variable substitution. This is true in category theory, when you talk about algebraic theories, and it's true in Haskell when you start noticing that various little languages are described by algebraic theories. But from this angle, I see no reason why it's _better_ to split variable substitution into two operations, first turning a tree into a tree of trees, and then flattening. It'd be nice if all Functor were a prerequisite for Monad, but even then there are still reasons for making (=) a primitive. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
Le Tue, 16 Oct 2012 11:58:44 -0400, Dan Doel dan.d...@gmail.com a écrit : On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote: join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem). As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law). This is the way it's typically presented. Can you demonstrate that it is the most important presentation? What do you mean by demonstrate? If you do not want to fit the mathematical presentation, then I have nothing to demonstrate, you have your point of view, I have mine and they differ. Now, if you want to fit the mathematical presentation, then a monad is an endofunctor with two natural transformations (η=return and μ=join) satisfying some laws. (when I write 'natural' I mean the mathematical definition of natural, not its common definition as something on which we think immediately, or something which is obvious). A natural transformation from S to T (where S and T are functors from a category C to a category D) is for each object 'x' of C, a morphism from S x to T x satisfying some property. return is a natural transformation from the Id functor to the M functor (where M is the monad), while join is a natural transformation from the MM functor to the M functor. If you want to express bind, that would be a natural transformation from a functor F to a functor G from C*×C (where C* is the opposite category of C) to the (Id↓M) comma-category. F would be defined as (a,b)↦Hom(a, M b) φ:Hom(a',a)×ψ:Hom(b,b')↦λ (f:Hom(a,M b)). (M ψ)∘f∘φ while G would be defined as (a,b)↦Hom(M a, M b) φ:Hom(a',a)×ψ:Hom(b,b')↦λ (f:Hom(M a, M b)). (M ψ)∘f∘(M φ) well, I guess it would be possible to define a monad with 'bind' as a natural transformation, but how complex it would be where 'join' is so simple. Plus 'return' and 'join' can be nicely composed to get the monad laws. I'd urge caution in doing so, too. For instance, there is a paper, Monads Need Not Be Endofunctors, that describes a generalization of monads to monads relative to another functor. Yes, so these are not monads. Your paper being written on 15 pages is some indication that it is more complex than simple monads. I will take a look on your relative adjunctions to understand what it exactly is. And there, bind is necessarily primary, because join isn't even well typed. I don't think it's written by mathematicians per se (rather, computer scientists/type theorists). But mathematicians have their own particular interests that affect the way they frame things, and that doesn't mean those ways are better for everyone. Once again, I never said that Monads with 'join' rather than 'bind' are better in all points. I only said that it better fits the mathematical point of view. Also note, that there is no true wall between sciences. Lot of things being interesting in some scientific domain can also be seen as interesting in some other scientific domain. As often some points it out, Haskellers are not very right in their definition of Monad, not because of the bind vs join (in fact in a Monad either of them can be defined from the other one), but because of the functor status of a Monad. A monad, should always be a functor (at least to fit its mathematical definition). And this problem with the functor has probably lead to the use of bind (which is polymorphic in two type variables) rather than join (which has only one type variable, and thus is simpler). The problem, is that when 'm' is a Haskell Monad which does not belong to the Functor class, we cannot define 'bind' in general from 'join'. I don't think Functor being a superclass of Monad would make much difference. For instance, Applicative is properly a subclass of Functor, but we don't use the minimal definition that cannot reproduce fmap on its own: class Functor f = LaxMonoidal f where unit :: f () pair :: f a - f b - f (a, b) Instead we use a formulation that subsumes fmap: fmap f x = pure f * x My background on that matter is not strong enough to discuss that point, I never used that stuff. Because those primitives are what we actually want to use, and it's more efficient to implement those directly than to go through some set of fully orthogonal combinators purely for the sake of mathematical purity. That is not a problem of purity, that is a problem of simplicity. And this goes for Monad, as well. For most of the monads in Haskell, the definition of join looks exactly like a definition of (= id), and it's not very arduous to extend that to (= f). But if we do define join, then we must recover (=) by
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
On Tue, Oct 16, 2012 at 1:19 PM, AUGER Cédric sedri...@gmail.com wrote: What do you mean by demonstrate? If you do not want to fit the mathematical presentation, then I have nothing to demonstrate, you have your point of view, I have mine and they differ. Now, if you want to I think the point is that Monad is not part of Haskell to satisfy mathematical (or categorical) purity, but to solve a particular set of problems. Those problems are best addressed with bind, and join works rather less well for them. Since one of those problems involves interfacing with the world outside of the program, an inefficient but categorically/mathematically more pure solution may not be a viable option in practice. Alternative Preludes which focus on other purposes are a dime a dozen; if you want a categorically pure Monad, nothing stops you from writing one and using it. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
I think the version below (with a Functor or Applicative superclass) is clearly the right answer if we were putting the prelude together from a clean slate. You can implement whichever is easiest for the particular monad, use whichever is most appropriate to the context (and add optimized versions if you prove to need them). I see no advantage in any other specific proposal, except the enormous advantage held by the status quo that it is already written, already documented, already distributed, and already coded to. Regarding mathematical purity of the solutions, this is in every way isomorphic to a monad, but we aren't calling it a monad because we are describing it a little differently than the most common way to describe a monad in category theory strikes me as *less* mathematically grounded than we are calling this a monad because it is in every way isomorphic to a monad. On Tue, Oct 16, 2012 at 7:03 AM, AUGER Cédric sedri...@gmail.com wrote: So I think that an implicit question was why wouldn't we have: class Monad m where return :: a - m a kleisli :: (a - m b) - (b - m c) - (a - m c) bind = \ x f - ((const x) = f) () join = id=id :: (m (m a) - m a) ___ 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] Why Kleisli composition is not in the Monad signature?
Not sure I really have anything substantial to contribute, but it's certainly true that if you see a - m b as a generalisation of the usual function type, a - b, then return generalises the identity and kleisli generalises function composition. This makes the types pretty memorable (and often the definitions too). Simon On 16 Oct 2012, at 20:14, David Thomas davidleotho...@gmail.com wrote: class Monad m where return :: a - m a kleisli :: (a - m b) - (b - m c) - (a - m c) Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thomp...@kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
On 15 October 2012 09:47, Michael Snoyman mich...@snoyman.com wrote: Hi all, I think I have a misunderstanding of how forkProcess should be working. Ultimately this relates to some bugs in the development version of keter, but I've found some behavior in a simple test program which I wouldn't have expected either, which may or may not be related. With the program at the end of this email, I would expect that, once per second, I would get a message printed from each forkIO'd green thread, the forked process, and the master process. And if I spawn 8 or less child threads that's precisely what happens. However, as soon as I up that number to 9, the child process is never run. The process is, however, created, as can be confirmed by looking at the process table. This only occurs when using the multithreaded runtime. In other words, compiling with ghc --make test.hs seems to always produce the expected output, whereas ghc --make -threaded test.hs causes the behavior described above. Having looked through the code for the process package a bit, my initial guess is that this is being caused by a signal being sent to the child process, but I'm not familiar enough with the inner workings to confirm or disprove this guess. If anyone has any ideas on this, I'd appreciate it. Not being familiar with the implementation, I'll just note that combining fork() with threads, as in the multithreaded RTS is going to have subtle bugs, no matter what. The only winning strategy is to not play that game. There are variants of this, but the meta-problem is that at the point in time when you call forkProcess, you must control all threads, ensuring that *all invariants hold*. Thus no locks held, no thread is in the C library, no foreign calls active etc. As an example, if one thread is in the C library doing some stdio, then the invariants in that library will not hold, and you cannot expect stdio to work in the child. This means that the only thing you can really do in the child process is call exec. These issues do not exist in the non-threaded world. Alexander Michael import System.Posix.Process (forkProcess, getProcessID) import Control.Concurrent (forkIO, threadDelay) import System.IO (hFlush, stdout) import System.Posix.Signals (signalProcess, sigKILL) import Control.Exception (finally) main :: IO () main = do mapM_ spawnChild [1..9] child - forkProcess $ do putStrLn starting child hFlush stdout loop child 0 print (child pid, child) hFlush stdout -- I've commented out the finally so that the zombie process stays alive, -- to prove that it was actually created. loop parent 0 -- `finally` signalProcess sigKILL child spawnChild :: Int - IO () spawnChild i = do _ - forkIO $ loop (spawnChild ++ show i) 0 return () loop :: String - Int - IO () loop msg i = do pid - getProcessID print (pid, msg, i) hFlush stdout threadDelay 100 loop msg (i + 1) ___ 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] forkProcess, forkIO, and multithreaded runtime
Since we're talking about forkIO here - not forkOS - is it possible to control the use of OS threads to avoid this problem? As I understand it, the problem is with real OS threads. A program running entirely in multiple `green' threads will fork to the same set of threads in the same state, creating no problem with internal state. I'm guessing this is why he sees the problem at 9 threads - maybe the runtime picks up another OS thread at that point. Of course one could link the unthreaded RTS, and that will cause everything, including runtime gc etc., to run in the parent thread, true? And there are some runtime options to control number of threads scheduled. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
The problems with forkProcess really are not Haskell's fault. You will find warnings in the documentation for C's fork(): There are limits to what you can do in the child process. To be totally safe you should restrict yourself to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. That's actually pretty scary. I'd always assumed that this was one of the reasons why the posix_spawn() function and its support crew were devised. Which reminds me that I expected to find posix_spawn() in System.Posix.Process but didn't. http://www.haskell.org/ghc/docs/7.4-latest/html/libraries/unix-2.5.1.1/System-Posix-Process.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
On Tue, 16 Oct 2012 21:55:44 +0200 Alexander Kjeldaas alexander.kjeld...@gmail.com wrote: There are variants of this, but the meta-problem is that at the point in time when you call forkProcess, you must control all threads, ensuring that *all invariants hold*. Thus no locks held, no thread is in the C library, no foreign calls active etc. As an example, if one thread is in the C library doing some stdio, then the invariants in that library will not hold, and you cannot expect stdio to work in the child. This means that the only thing you can really do in the child process is call exec. Further, you can only call exec if you make sure that the exec correctly reverts everything back to a state where those invariants hold. Mostly, this is automatic as resources get freed on exec and do the right thing. Locks on file descriptors that aren't closed on exec will leave dangling locks, and locks on files that are closed on exec will unexpectedly close them in the parent. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Issue building ghc on NetBSD/amd64
On Mon, Oct 15, 2012 at 8:51 PM, Chatsiri Ratana insider...@gmail.comwrote: Should be not include intermediate C by call .hc file? It should be using flags as below. ./configure --build=x86_64-unknown-netbsd --host=x86_64-unknown-netbsd --target=x86_64-unknown-netbsd Change flag in mk/build.mk for porting code before running command. Just tried changing the flag in build.mk, but I get the same error. Also, I'm pretty sure I need the --enable-hc-boot flag. Without it, I get: configure: error: GHC is required unless bootstrapping from .hc files. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Issue building ghc on NetBSD/amd64
Quoth lhagan lhaga...@gmail.com, Just tried changing the flag in build.mk, but I get the same error. Also, I'm pretty sure I need the --enable-hc-boot flag. Without it, I get: configure: error: GHC is required unless bootstrapping from .hc files. Unless I've missed a whole lot of progress on this matter, it's going to be much more work than just getting the flags right. Several years ago, I managed to build 6.8, by starting with an OpenBSD port of 6.6 as an hc donor, and of course building 6.6 on NetBSD, and then using 6.6 to build 6.8. There's a great deal of debugging and patching that needs to be done in the process, some of it already done for i386 and some novel to amd64. I presented it to the NetBSD Haskell maintainer, but obviously it's a low priority - I think in the intervening years, you're the second person to mention it. If that individual (whose identity I can't recall at the moment) has a working NetBSD/amd64 port at this time, of any version, that would be extremely helpful; unfortunately I don't, I think my amd64 hardware is defunct. (I don't think I got the interpreter working, by the way, and that also usually means no haddock, etc.) Today, you'd be obliged to follow the same course, but probably would have to build one or two intermediate GHC versions as I doubt that 6.6 could build the current version. I understand the current version is not able to be bootstrapped from hc files at all. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] License of CloudHaskell code write by Haskell language.
On Tue, Oct 16, 2012 at 6:20 PM, Edsko de Vries edskodevr...@gmail.comwrote: Hi, The version of Cloud Haskell you cite is a prototype. I recommend you use the 'distributed-process' package instead; it is licensed under BSD3. Edsko Hello All, I finding issues for forking project in order to develop distributed-process. I have idea develop distributed-process for other services not only Azure system. Who have an idea develop distributed-process? In distributed-process have work in progress for supporting services follow to this point[1]. 1) distributed-process-azure: Azure backend for Cloud Haskell (work in progress) 2) azure-service-api: Haskell bindings for the Azure service API (work in progress) I interest in concurrent/parallel programming by Haskell. My view Haskell seem to be doing well in concurrent/parallel concepts. [1]https://github.com/haskell-distributed/distributed-process Thank in advance, Chatsiri Rattana -- : ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
