Re: [Haskell-cafe] createProcess shutting file handles
Hi What have I done wrong? Did createProcess close the handle, and is there a way round this? The docs for runProcess says: Any Handles passed to runProcess are placed immediately in the closed state. but the equivalent seems to be missing from the documentation for createProcess. However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Telnet handshaking
Hello, Are there any Haskell libraries out there that implement telnet? Bare sockets are a good approximation, but I'm looking for a library that understands the escape sequences specific to telnet. Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A day with xmonad
I have blogged my experience of trying out xmonad with Fedora 10 at http://colina.demon.co.uk/?q=node/534 . -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Feynman on Mathematics and Physics
Just came across this 6 part video of Feynman lecture on relationship of mathematics and physics. http://www.youtube.com/watch?v=W1jIPzjFU_Ue Enjoy, Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Delimited continuations: please comment
On Sat, Feb 14, 2009 at 2:04 AM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: liftIO is defined there, I believe. Many of the monad modules re-export it with their MonadTrans definitions, but apparently Control.Monad.CC doesn't so you need to go to the source. Yeah, I knew the answer :D It was sort of a joke... Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess shutting file handles
On Sun, 2009-02-15 at 09:24 +, Neil Mitchell wrote: Hi What have I done wrong? Did createProcess close the handle, and is there a way round this? The docs for runProcess says: Any Handles passed to runProcess are placed immediately in the closed state. but the equivalent seems to be missing from the documentation for createProcess. However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. close_fds :: Bool Close all file descriptors except stdin, stdout and stderr in the new process This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: permuting a list
Heinrich Apfelmus apfel...@quantentunnel.de writes: The answer is a resounding yes and the main idea is that shuffling a list is *essentially the same* as sorting a list; the minor difference being that the former chooses a permutation at random while the latter chooses a very particular permutation, namely the one that sorts the input. For the full exposition, see http://apfelmus.nfshost.com/random-permutations.html I haven't been following the thread, but my initial reaction would have been something like use System.Random.randoms to get a list rs and then do (roughly) randomPerm = map snd . sortBy (compare `on` fst) . zip rs How bad is that? I mean, how unfair does it get? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help with Menu item handlers in gtk2hs with glade
I designed a basic GUI with Menu bar and menu items in glade. I use the glade bindings in haskell to get the menu item using xmlGetWidget and castToMenuItem function. I set a *onActivateItem* handler for this menuitem. However this is not working. I saw the glade file and it has a signal function in the xml. I tried to use the same function name, but it doesn't work either. Any suggestions on what I might be doing wrong here and how to get menu item handlers working. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: permuting a list
Jon Fairbairn wrote: Heinrich Apfelmus writes: The answer is a resounding yes and the main idea is that shuffling a list is *essentially the same* as sorting a list; the minor difference being that the former chooses a permutation at random while the latter chooses a very particular permutation, namely the one that sorts the input. For the full exposition, see http://apfelmus.nfshost.com/random-permutations.html I haven't been following the thread, but my initial reaction would have been something like use System.Random.randoms to get a list rs and then do (roughly) randomPerm = map snd . sortBy (compare `on` fst) . zip rs How bad is that? I mean, how unfair does it get? It's fair, but may duplicate elements, i.e. it doesn't necessarily create a permutation. For example, rs could be something like rs = [5,3,3,3,2,4] Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: permuting a list
Heinrich Apfelmus wrote: Jon Fairbairn wrote: Heinrich Apfelmus writes: The answer is a resounding yes and the main idea is that shuffling a list is *essentially the same* as sorting a list; the minor difference being that the former chooses a permutation at random while the latter chooses a very particular permutation, namely the one that sorts the input. For the full exposition, see http://apfelmus.nfshost.com/random-permutations.html I haven't been following the thread, but my initial reaction would have been something like use System.Random.randoms to get a list rs and then do (roughly) randomPerm = map snd . sortBy (compare `on` fst) . zip rs How bad is that? I mean, how unfair does it get? It's fair, but may duplicate elements, i.e. it doesn't necessarily create a permutation. For example, rs could be something like rs = [5,3,3,3,2,4] How about using random doubles? randomPerm xs = fmap (map snd . sort . flip zip xs) rs where rs = fmap (randoms . mkStdGen) randomIO :: IO [Double] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: permuting a list
On Sun, Feb 15, 2009 at 9:47 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: It's fair, but may duplicate elements, i.e. it doesn't necessarily create a permutation. For example, rs could be something like rs = [5,3,3,3,2,4] But our sort doesn't discard values when the keys are the same. For example, [1,2,3,4] == map snd . sortBy (compare `on` fst) . zip (repeat 1) $ [1,2,3,4] Nothing gets duplicated. Or did I miss something? -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Race condition possible?
I'm not sure what you mean with Time on different cores does not progress monotonically. Time could come from a dedicated clock device. E.g. in the broadcast television sector a time signal is distributed across all hardware components to keep them all in sync within some margin, or you could use the clock from a local sound card, etc. I guess each operating system provides such a clock. I'm also not sure about the performance penalty. One would surely get a penalty with a global lock on the clock (serializing time), but I think the problem can be solved with a local lock per stream. But I would have to think about this more before claiming such things :-) Maybe you could elaborate a bit more on your claims? On Sun, Feb 15, 2009 at 5:38 AM, Bryan O'Sullivan b...@serpentine.comwrote: 2009/2/14 Peter Verswyvelen bugf...@gmail.com If you have two streams of time/value pairs - using MVars as write-once sampling variables - and both streams are fed from another thread (e.g. timers firing), and you want to merge these two streams into a single stream with monotonic time stamps, then you want to be able to check if at time t an occurrence exists in a stream. What you want to do isn't actually achievable on multi-processor machines without some form of mutual exclusion. Time on different cores does not progress monotonically, and you'll pay an enormous performance penalty to do what you want to do (the nature of which is somewhat unclear). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Telnet handshaking
On Sun, Feb 15, 2009 at 10:25, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Are there any Haskell libraries out there that implement telnet? Bare sockets are a good approximation, but I'm looking for a library that understands the escape sequences specific to telnet. I think Yogurt http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Yogurt should implement this. If I'm right then you could simply extract necessary code. All best Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: permuting a list
Felipe Lessa wrote: Heinrich Apfelmus wrote: It's fair, but may duplicate elements, i.e. it doesn't necessarily create a permutation. For example, rs could be something like rs = [5,3,3,3,2,4] But our sort doesn't discard values when the keys are the same. For example, [1,2,3,4] == map snd . sortBy (compare `on` fst) . zip (repeat 1) $ [1,2,3,4] Nothing gets duplicated. Or did I miss something? Oops, right, elements won't be duplicated by sortBy . I was thinking of randomPerm xs = zipWith (!!) xs rs But you do loose fairness. After all, you are mapping n^n possibilities for rs to n! permutations and because the latter does not divide the former, there is no way to make that balanced for general n . For instance, when the sorting algorithm is stable and you want to permute say abcde, then 'a' is more likely to be in front of 'b' because of those cases where both 'a' and 'b' are zipped to the same number. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help with Menu item handlers in gtk2hs with glade
On Sun, 2009-02-15 at 16:48 +0530, Lakshmi Narasimhan wrote: I designed a basic GUI with Menu bar and menu items in glade. I use the glade bindings in haskell to get the menu item using xmlGetWidget and castToMenuItem function. I set a *onActivateItem* handler for this menuitem. However this is not working. You're not the only one confused, I've never really understood the profusion of actions on Gtk+ menu items, but onActivateLeaf seems to be the one to use. I saw the glade file and it has a signal function in the xml. I tried to use the same function name, but it doesn't work either. Ignore that, it only works for C code. Any suggestions on what I might be doing wrong here and how to get menu item handlers working. There are three places to look at for help, the demos, the API documentation and the gtk2hs-users mailing list. The demos: -- Take a look at the menu demo that comes with gtk2hs (in the gtk2hs tarball under demo/menu/MenuDemo.hs). You'll notice it uses onActivateLeaf rather than onActivateItem. The API docs: - http://haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-MenuComboToolbar-MenuItem.html#7 (linked from http://haskell.org/gtk2hs/documentation/) say: onActivateItem :: MenuItemClass self = self - IO () - IO (ConnectId self) Emitted when the user chooses a menu item that has a submenu. This signal is not emitted if the menu item does not have a submenu. onActivateLeaf :: MenuItemClass self = self - IO () - IO (ConnectId self) The user has chosen the menu item. This is the only function applications normally connect to. It is not emitted if the item has a submenu. The mailing list: - http://haskell.org/gtk2hs/development/#mailing_lists Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess shutting file handles
On Sun, 2009-02-15 at 11:06 +, Duncan Coutts wrote: On Sun, 2009-02-15 at 09:24 +, Neil Mitchell wrote: Hi What have I done wrong? Did createProcess close the handle, and is there a way round this? The docs for runProcess says: Any Handles passed to runProcess are placed immediately in the closed state. but the equivalent seems to be missing from the documentation for createProcess. However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. close_fds :: Bool Close all file descriptors except stdin, stdout and stderr in the new process This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Telnet handshaking
Krzysztof Skrzętnicki wrote: On Sun, Feb 15, 2009 at 10:25, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Are there any Haskell libraries out there that implement telnet? Bare sockets are a good approximation, but I'm looking for a library that understands the escape sequences specific to telnet. I think Yogurt http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Yogurt should implement this. If I'm right then you could simply extract necessary code. Actually, my question is related to the development of Yogurt. :-) Yogurt should understand telnet but doesn't; it just uses a bare socket. Before I implement any telnet-specific stuff myself, I want to make sure I don't reinvent the wheel; hence my question. Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: permuting a list
See http://okmij.org/ftp/Haskell/perfect-shuffle.txt Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Intergalactic Telefunctors
Came up with an alternative to the container metaphor for functors that you might find amusing: http://syntax.wikidot.com/blog:9 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] forall ST monad
I'm having trouble understanding the explanation of the meaning of the signature of runST at http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? I'm currently only using forall in combination with type classes, as in data MVC m v = forall c. Controller c = MVC m v c However - as the article mentions - forall can also be used to constrain the scope of type variables, but I don't get it yet. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Race condition possible?
Peter Verswyvelen bugf...@gmail.com wrote: Time on different cores does not progress monotonically Two cores executing the same code are not guaranteed to finish them in the same time span, due to caching, temperature, voltage jaggies, quantum-mechanic inference, ... -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
Gregg Reynolds wrote: Came up with an alternative to the container metaphor for functors that you might find amusing: http://syntax.wikidot.com/blog:9 You seem to describe Bifunctors (two objects from one category are mapped to one object in another category), but Haskell's Functor class is about Endofunctors (one object in one category is mapped to an object in the same category). Therefore, your insistence on the alien universe being totally different from our own is somewhat misleading, since in Haskell, we are specifically dealing with the case that the alien universe is just our own. Moreover, you are mixing in the subject of algebraic data types (all we know about (a, b) is that (,), fst and snd exist). Personally, I do not see why one should explain something easy like functors in terms of something complicated like quantum entanglement. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Low-level high-level languages?
Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
On Sun, Feb 15, 2009 at 11:09 AM, Tillmann Rendel ren...@cs.au.dk wrote: Gregg Reynolds wrote: Came up with an alternative to the container metaphor for functors that you might find amusing: http://syntax.wikidot.com/blog:9 You seem to describe Bifunctors (two objects from one category are mapped to one object in another category), but Haskell's Functor class is about Endofunctors (one object in one category is mapped to an object in the same category). Therefore, your insistence on the alien Yeah, it needs work, but close enough for a sketch. BTW, I'm not talking about Haskell's Functor class, I guess I should have made that clear. I'm talking about category theory, as the semantic framework for thinking about Haskell. universe being totally different from our own is somewhat misleading, since in Haskell, we are specifically dealing with the case that the alien universe is just our own. The idea is that each type (category) is a distinct universe. The essential point about functors cross boundaries from one category to another. Moreover, you are mixing in the subject of algebraic data types (all we know about (a, b) is that (,), fst and snd exist). It's straight out of category theory. See Pierce http://mitpress.mit.edu/catalog/item/default.asp?ttype=2tid=7986 Personally, I do not see why one should explain something easy like functors in terms of something complicated like quantum entanglement. The metaphor is action-at-a-distance. Quantum entanglement is a vivid way of conveying it since it is so strange, but true. Obviously one is not expected to understand quantum entanglement, only the idea of two things linked invisibly across a boundary. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess shutting file handles
Hi However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. close_fds :: Bool Close all file descriptors except stdin, stdout and stderr in the new process This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. One guiding principle of resource management is that whoever opens/allocates something should release/free it. i.e. if you did the malloc you do the free. For that reason it seems weird that I call openFile but someone else calls hClose on my behalf. Plus, in my particular application, the above behaviour is necessary or I'm going to have to write to a file, open that file, and copy it over to my intended file (which is what I will end up doing, no doubt!) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
Quantum entanglement is related to a different kind of categorical product. So, the metaphor is misleading. But, that being said : I want to thank you for your blog. A bit polemic but very interesting. Christophe. Came up with an alternative to the container metaphor for functors that you might find amusing: http://syntax.wikidot.com/blog:9 ___ 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] forall ST monad
On 2009 Feb 15, at 11:50, Peter Verswyvelen wrote: I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? You could think about it as playing a dirty trick on the typechecker. The trick is that the scope of the forall-ed type is limited by the surrounding parentheses; therefore there is no way for the typechecker to know the type anywhere else, so it won't let you talk about it. Which means you can't use it outside the parentheses. Both the forall and the parentheses are necessary for this trick; if it were a concrete type, the typechecker knows it, and if it were a simple type variable its type would exist at the top level and therefore be available for type inference. The combination of the forall (which makes the type slippery) inside the parentheses (which limits its scope) prevents top level type inference and leaves the compiler with no way to get at the type from outside, and if you can't get at the type you can't do anything with the value. The result is that the value is trapped inside the ST monad. If you try to use it you get the escapes error, which really means I have no way to assign a type to this reference, so you can't touch it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
On Sun, Feb 15, 2009 at 11:53 AM, Tillmann Rendel ren...@cs.au.dk wrote: Gregg Reynolds wrote: BTW, I'm not talking about Haskell's Functor class, I guess I should have made that clear. I'm talking about category theory, as the semantic framework for thinking about Haskell. Don't forget the part explaining this is just a sketch. In that case, I even less see why you are not introducing category theory proper. Certainly, if one wants to use a semantic framework for thinking about something, one should use the real thing, not some metaphors. The idea is that each type (category) is a distinct universe. The essential point about functors cross boundaries from one category to another. What are the categories you are talking about here? Take your pick. Moreover, you are mixing in the subject of algebraic data types (all we know about (a, b) is that (,), fst and snd exist). It's straight out of category theory. See Pierce http://mitpress.mit.edu/catalog/item/default.asp?ttype=2tid=7986 Which part specifically? Sections 1.5, 1.6, 1.9, 2.1, etc. Personally, I do not see why one should explain something easy like functors in terms of something complicated like quantum entanglement. The metaphor is action-at-a-distance. Quantum entanglement is a vivid way of conveying it since it is so strange, but true. Obviously one is not expected to understand quantum entanglement, only the idea of two things linked invisibly across a boundary. How does the fact that a morphism exists between two objects in some category link these objects together? It doesn't change the objects at all. In your own words: How can action (at-a-distance) be about mathematical values? Not between two objects in some category; between two objects in different categories. That's the whole point. Functors preserve structure. Action-at-a-distance is a metaphor meant to enliven the concept. You use a map in your home category to map remote objects, by beaming it up through the telefunctor. Your map stays home but is quantum entangled with the remote map. Heh heh. I'm not saying it's for everybody, but I think it's kinda fun. -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
Gregg Reynolds wrote: Action-at-a-distance is a metaphor meant to enliven the concept. Kind of like the container metaphor? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
On Sun, Feb 15, 2009 at 12:45 PM, Anton van Straaten an...@appsolutions.com wrote: Gregg Reynolds wrote: Action-at-a-distance is a metaphor meant to enliven the concept. Kind of like the container metaphor? Yes, only, different. Non-pernicious. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
2009/2/15 Gregg Reynolds d...@mobileink.com: The metaphor is action-at-a-distance. Quantum entanglement is a vivid way of conveying it since it is so strange, but true. Obviously one is not expected to understand quantum entanglement, only the idea of two things linked invisibly across a boundary. This is unrelated to haskell, but it's so common a misconception that I have to debunk it. What actually happens, if you run through the math, is that when you entangle two particles it affects the entangled property such that, when you later start spreading information about the entangled state - the universe is effectively divided in whatever the possible results are, MWI style, but once the information contacts the related entangled information from the other particle, inconsistent results cancel out and you get a big fat zero for a wavefunction. Consistent results reinforce, so it's still unitary as a whole. See, it all adds up to normality. Pay no attention to the bazillion timelines being continually destroyed behind the scenes, please; anyhow, you can never actually *observe* inconsistency, so if your notion of self is flexible enough you can just claim you continue along the consistent timeline. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
On Sun, Feb 15, 2009 at 7:54 PM, Svein Ove Aas svein@aas.no wrote: 2009/2/15 Gregg Reynolds d...@mobileink.com: The metaphor is action-at-a-distance. Quantum entanglement is a vivid way of conveying it since it is so strange, but true. Obviously one is not expected to understand quantum entanglement, only the idea of two things linked invisibly across a boundary. This is unrelated to haskell, but it's so common a misconception that I have to debunk it. What actually happens, if you run through the math, is that when you entangle two particles it affects the entangled property such that, when you later start spreading information about the entangled state - the universe is effectively divided in whatever the possible results are, MWI style, but once the information contacts the related entangled information from the other particle, inconsistent results cancel out and you get a big fat zero for a wavefunction. Consistent results reinforce, so it's still unitary as a whole. See, it all adds up to normality. Pay no attention to the bazillion timelines being continually destroyed behind the scenes, please; anyhow, you can never actually *observe* inconsistency, so if your notion of self is flexible enough you can just claim you continue along the consistent timeline. Oh yeah. The crucial point is, this view has no spooky action at a distance involved. The speed of light limit is maintained - nice and elegant, really. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help needed with apache config for hackage
* Duncan Coutts duncan.cou...@worc.ox.ac.uk [2009-02-13 12:19:29 +]: Can we do that just for one user agent? I don't think we want to use non-standard stuff in general. Apparently Content-Disposition is not in the official HTTP spec, but IE is known to follow it. Well, it's mentioned in RFC 2616[1], and I'd expect it to just have no effect in any user agent that doesn't implement it, so this doesn't seem like a huge concern. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1 -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Peter Verswyvelen-2 wrote: I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? The primary source is if I'm not mistaken, the following State in Haskell paper: http://research.microsoft.com/en-us/um/people/simonpj/Papers/state-lasc.ps.gz Having said that, I'm not sure about the statement on page 9 that readVar v simply does not have type forall s. ST s Bool. The variable v could be of type forall s. MutVar s Bool, in which case all of runST (readVar v) typechecks. The sticking point really arises from runST (newVar True). So there isn't really the other way round, but rather only one way. Am I misreading something? A minor nit, to be sure. -- View this message in context: http://www.nabble.com/forall---ST-monad-tp22024677p22026629.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intergalactic Telefunctors
On Sun, 2009-02-15 at 18:53 +0100, Tillmann Rendel wrote: Gregg Reynolds wrote: BTW, I'm not talking about Haskell's Functor class, I guess I should have made that clear. I'm talking about category theory, as the semantic framework for thinking about Haskell. In that case, I even less see why you are not introducing category theory proper. Certainly, if one wants to use a semantic framework for thinking about something, one should use the real thing, not some metaphors. The sooner you realize that Gregg is, apparently, only interested in half-baked philosophizing and wordplay, the better off you'll be. Of the things he claims to be interested in, Haskell, category theory, formal semantics, none have yet made an appearance on his blog. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interactive debugging?
Can this be done with Haskell? In particular, I'm using ghc 6.10.1. Can I get symbols for use with gdb, for instance? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Hello all, I just released two new packages on Hackage, stateful-mtl and pqueue-mtl. Stateful-mtl provides an ST monad transformer, several useful operations on generic monad transformers, and a monad transformer intended to cleanly externally wrap operations on a mutable array (including resizing operations). It provides wrappers to generic MArray instances, an array based on an IntMap, and a specialized transformer that completely wraps what is essentially a pared-down STArray into a monadic interface that doesn't mention ST at all. pqueue-mtl provides implementations of several structures supporting a generic 'single-in, single-out' paradigm (encapsulated in a typeclass named Queuelike), including stacks, queues, and several implementations of priority queues, including primarily a PQueue structure (in Data.Queue.PQueue) based on a pairing heap. In addition, the package provides monad transformers encapsulating single-threaded access to a Queuelike structure, and provides a fully encapsulated array-backed heap implementation (using the array transformers from stateful-mtl). The primary motivation for all this was to improve elegance of graph algorithms. The following is an implementation of a shortest-path algorithm based on the fgl library that returns an IntMap mapping each node to its parent in a shortest-path tree: type DijkstraM gr a b = IntMapT (Node, b) (PQueueT (Edge :- b) (State (gr a b))) expand :: (Num b, Ord b, MonadQueue (Edge :- b) m) = b - Context a b - m () expand d cxt = let x = node' cxt -- node being expanded in queueInsertAll [(y, x) :- (d + w) | (y, w) - lsuc' cxt] dijkstraM :: (Graph gr, Num b, Ord b) = DijkstraM gr a b () dijkstraM = execMaybeT $ forever $ do -- this line repeats a monadic operation until a pattern match fails False - gets isEmpty Just ((v, w) :- d) - queueExtract statefully (match v) =? \ c - writeAt v (w, d) expand d c -- performs an action if the match does not return Nothing dijkstra :: (Graph gr, Num b, Ord b) = gr a b - Node - IntMap (Node, b) dijkstra g v = evalState (runQueueTOn (execIntMapT_ dijkstraM) [(v, v) :- 0]) g As an imperative programmer for many years, this is pretty much the most intuitive implementation of Dijkstra's algorithm that I've seen. Let me know what you think. Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Amazing
So IMO static typing is good, but it's only with functional programming that it really shines. You can go one step further: if you start using dependent types, you'll see that it gets yet harder to get your program to type-check, and once it does, you don't even bother to run it since it's so blindingly obvious that it's correct. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Looking for pointfree version
import Control.Applicative data Pair a = a :*: a instance Functor Pair where f `fmap` (x :*: y) = f x :*: f y instance Applicative Pair where (f :*: g) * (x :*: y) = f x :*: f y The last f needs to be a g. pure x = x :*: x pointfree :: (a - b - c) - Pair a - Pair b - Pair c --pointfree o x y = pure o * x * y pointfree = ((*) .) . (*) . pure -- in the applicative paper notation: --pointfree o x y = [| o x y |] Very nice. Aside: I wonder how much work it would be to extend the pointfree tool to infer such equalities? -- View this message in context: http://www.nabble.com/Looking-for-pointfree-version-tp21913653p22027350.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Amazing
This must be why there are no good compilers for dependently typed languages. :) On Sun, Feb 15, 2009 at 9:40 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: So IMO static typing is good, but it's only with functional programming that it really shines. You can go one step further: if you start using dependent types, you'll see that it gets yet harder to get your program to type-check, and once it does, you don't even bother to run it since it's so blindingly obvious that it's correct. Stefan ___ 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] ANNOUNCE: pqueue-mtl, stateful-mtl
Stateful-mtl provides an ST monad transformer, Is this safe? e.g. does it work correctly on [], Maybe etc? If not this should be flagged very prominently in the documentation. Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Amazing
How practical is this dependent types thing? I hear a lot about this from really clever people who are usually 10 years ahead of their time :) Actually, back in the eighties when I was an assembly language hacker, I didn't want to switch to Pascal or C since I found the types in those languages too weak. C++ changed that with templates, and then I switched (only to find out that no C++ compiler existed that would not crash on my fully templated programs ;-). What I really wanted was a way to program the type checks myself; verify constraints/assertions at compile time, and if the constraint or assertion could not be done at compile time, get a warning or an error (or bottom if the custom type checking program is stuck in an endless loop ;-) Of course back then I was even more naive than I am now, so those things are easier said than done I guess. But if I understand it correctly, dependent types are a bit like that, values and types can inter-operate somehow? On Sun, Feb 15, 2009 at 9:40 PM, Stefan Monnier monn...@iro.umontreal.cawrote: So IMO static typing is good, but it's only with functional programming that it really shines. You can go one step further: if you start using dependent types, you'll see that it gets yet harder to get your program to type-check, and once it does, you don't even bother to run it since it's so blindingly obvious that it's correct. Stefan ___ 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] Low-level high-level languages?
You might want to take a look at Timber http://www.timber-lang.org On Sun, Feb 15, 2009 at 6:22 PM, Maurício briqueabra...@yahoo.com wrote: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Thanks, Maurício ___ 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] Help with Stack Space Overflow / Memory Issues
Hello, I'm writing a small program to process Delicious [1] RSS feeds. I like look at the recent feeds to see what others have bookmarked recently. But, there are a lot of duplicates in the recent feeds as an entry is shown for each person who bookmarks an individual URL. I decided to write a small program that would trim out those that I've seen before. I wrote a small program that read a feed (initially just a on-disk copy of an RSS feed) and removed the duplicate items just within that feed. It worked great. Then, I wanted to add persistence, so this would maintain state from one run to the next. I decided to use Data.Binary to serialize the Data.Map I was using and re-load it each time. Unfortunately, making this change caused a Stack Space Overflow error and I couldn't track down what was wrong. This was with GHC 6.8.2. I recently upgraded to GHC 6.10.1 and the memory just grows unbounded, until it actually locks up my machine. This happens even when I comment out the code for the serialization / de-serialization of the map, so essentially the only difference from my prior version is the function where the map is initialized returns IO [Item] instead of [Item]. The latest version of my code is up on github [2], and the sample RSS feed I was processing is included in the repo. I'd appreciate some help in how to attack this problem. I've even tried profiling this (back when I was using 6.8.2) and there was nothing enlightening there, at least with my limited Haskell experience. I am unsure of how to get this to work, or if the problem is even my code. Additionally, I am unsure if my serialization code would work anyway. Because Haskell is not pass-by-reference, would the changes to the seenMap propogate back to my deDupWithSerializedMap function where it is serialized? If not, how would I go about doing this? I think part of my problem might be the difference between pure and impure code and how to separate it. Thanks for the help! [1] http://www.delicious.com/ [2] http://github.com/Nafai77/recent-feeds/tree/master --- Travis B. Hartwell Software Toolsmith Blog: http://www.travishartwell.net/blog Where to find me: http://www.travishartwell.net/blog/static/where_to_find_me ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Epic failure
OK, what did I do wrong here?
module Main () where
import Data.List
top = 10 ^ 8 :: Int
main = do
let numbers = [1 .. top]
print $ foldl' (+) 0 numbers
-- Runtime is 20 seconds.
#include stdio.h
int main(void)
{
int total = 0;
int n;
for (n = 1, n 1; n++)
total += n;
printf(%d, n);
}
// Runtime is 0.8 seconds.
module Main () where
import Data.List
top = 10 ^ 8 :: Int
kernel i o = if i top then o `seq` kernel (i+1) (o+i) else o
main = do
print $ kernel 1 0
-- Runtime is 0.5 seconds.
Clearly these two nearly identical Haskell programs should have exactly
the same runtime. Instead, one is 40x slower. Clearly something has gone
catastrophically wrong here. The whole point of GHC's extensive
optimiser passes are to turn the first example into the second example -
but something somewhere hasn't worked. Any suggestions?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Sun, Feb 15, 2009 at 09:59:28PM -, Sittampalam, Ganesh wrote: Stateful-mtl provides an ST monad transformer, Is this safe? e.g. does it work correctly on [], Maybe etc? If not this should be flagged very prominently in the documentation. It is not safe: it has the same problem as the STMonadTrans package, discussed recently here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016554.html The following code demonstrates that STT violates referential transparency: import Control.Monad import Data.STRef import Control.Monad.Trans import Control.Monad.ST.Trans data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show instance Monad Tree where return = Leaf Leaf a = k = k a Branch l r = k = Branch (l = k) (r = k) foo :: STT s Tree Integer foo = do x - liftST $ newSTRef 0 y - lift (Branch (Leaf 1) (Leaf 2)) when (odd y) (liftST $ writeSTRef x y) liftST $ readSTRef x main :: IO () main = do print $ runSTT foo let Branch _ (Leaf x) = runSTT foo print x outputting: Branch (Leaf 1) (Leaf 1) 0 Demanding the value in the left Leaf affects the value seen in the right Leaf. Regards, Reid ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Epic failure
OK, what did I do wrong here?
When making a request for help on a compiler issue, you failed to include key
information to make it possible to reproduce your problem, and what you did
include was broken or incorrect.
The three programs that submitted don't do even do the same thing.
Let's look into this further.
* Program 1:
module Main () where
import Data.List
top = 10 ^ 8 :: Int
main = do
let numbers = [1 .. top]
print $ foldl' (+) 0 numbers
-- Runtime is 20 seconds.
Well, let's see if we can reproduce this:
$ ghc -O2 A.hs --make
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
$ time ./A
50005000
./A 1.54s user 0.01s system 98% cpu 1.571 total
Nope. OK, so this seems like user error. Without more info about how you
conducted your experiment, the results are meaningless.
My guess is that you compiled it without optimisations?
Nope, not that,
$ ghc -O0 --make A.hs
$ time ./A
50005000
./A 2.65s user 0.01s system 99% cpu 2.667 tota
So even with all optimisations disabled, it is still an order of magnitude
faster than the number you presented. Resolution: invalid. Not reproducible.
* Program 2
#include stdio.h
int main(void)
{
int total = 0;
int n;
for (n = 1, n 1; n++)
total += n;
printf(%d, n);
}
// Runtime is 0.8 seconds.
Ok. Let's try this then, a C program:
$ gcc t.c
t.c: In function ‘main’:
t.c:8: error: expected ‘;’ before ‘)’ token
Ah, an incorrect C program. Correcting the OP's typo:
$ time ./a.out
1
./a.out 0.41s user 0.00s system 100% cpu 0.416 total
So its actually a different program. Is this supposed to print 'total'?
This program seems wrong in a number of other ways too.
Resolution: non-sequitor
Program 3
module Main () where
import Data.List
top = 10 ^ 8 :: Int
kernel i o = if i top then o `seq` kernel (i+1) (o+i) else o
main = do
print $ kernel 1 0
-- Runtime is 0.5 seconds.
Clearly these two nearly identical Haskell programs should have exactly
the same runtime. Instead, one is 40x slower. Clearly something has gone
catastrophically wrong here. The whole point of GHC's extensive optimiser
passes are to turn the first example into the second example - but
something somewhere hasn't worked. Any suggestions?
Ok, another program. Let's try this.
$ ghc -O2 B.hs --make
[1 of 1] Compiling Main ( B.hs, B.o )
Linking B ...
$ time ./B
49995000
./B 0.18s user 0.00s system 98% cpu 0.186 total
Oh, this is produces yet another result. In 0.186 seconds.
So, going back to the original question, what did you do wrong?
If you're seeking input for a technical error relating to performance, you
should have, but failed to:
* Use programs that implement the same algorithm
* Indicate which compiler versions/optimisations/architecture you're on
* State what you expected the results to be.
Besides the technical aspects, your presentation categorises the post somwhere
between internet
crank and internet troll, as:
* You used an inflammatory title, which doesn't inspire trust.
* You jumped to conclusions on the fundamental nature of a technology,
striking at its reasons for existing, without considering to recheck your
assumptions.
So yes, epic fail. And after three years of this, I'm not hopeful.
But perhaps you can take some lessons from this post to improve your next one?
Now, assuming good faith, and you were just very confused about what you were
measuring, or how to measure it, or how to ask for help in a technical forum,
here's some more fun: let's write your 1st program, and see if GHC can
transform it into your 3rd program.
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ uname -msr
Linux 2.6.28-ARCH x86_64
$ gcc --version
gcc (GCC) 4.3.3
$ ghc-pkg list uvector
uvector-0.1.0.3
Here's a a program written with combinators in a high level style (and using a
library written in a high level way):
import Data.Array.Vector
main = print . sumU . enumFromToU 0 $ (10^8 :: Int)
Compiling it,
$ ghc -O2 --make C.hs
Which yields the following core,
$wfold_s15D :: Int# - Int# - Int#
$wfold_s15D =
\ (ww1_s15a :: Int#) (ww2_s15e :: Int#) -
case # ww2_s15e ww_s154 of wild_a12I {
False -
$wfold_s15D
(+# ww1_s15a ww2_s15e) (+# ww2_s15e 1);
True - ww1_s15a
Because GHC knows how to optimise loops of these forms.
And the resulting assembly is pretty nice,
s16o_info:
.Lc17g:
cmpq 6(%rbx),%rdi
jg
Re: [Haskell-cafe] Re: Amazing
It's true that you can do program the type checker even more if you have dependent types, but first you should look into what you can do in Haskell. You can do a lot with type classes. -- Lennart 2009/2/15 Peter Verswyvelen bugf...@gmail.com: How practical is this dependent types thing? I hear a lot about this from really clever people who are usually 10 years ahead of their time :) Actually, back in the eighties when I was an assembly language hacker, I didn't want to switch to Pascal or C since I found the types in those languages too weak. C++ changed that with templates, and then I switched (only to find out that no C++ compiler existed that would not crash on my fully templated programs ;-). What I really wanted was a way to program the type checks myself; verify constraints/assertions at compile time, and if the constraint or assertion could not be done at compile time, get a warning or an error (or bottom if the custom type checking program is stuck in an endless loop ;-) Of course back then I was even more naive than I am now, so those things are easier said than done I guess. But if I understand it correctly, dependent types are a bit like that, values and types can inter-operate somehow? On Sun, Feb 15, 2009 at 9:40 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: So IMO static typing is good, but it's only with functional programming that it really shines. You can go one step further: if you start using dependent types, you'll see that it gets yet harder to get your program to type-check, and once it does, you don't even bother to run it since it's so blindingly obvious that it's correct. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
On Sun, Feb 15, 2009 at 11:50 AM, Kim-Ee Yeoh a.biurvo...@asuhan.com wrote: Having said that, I'm not sure about the statement on page 9 that readVar v simply does not have type forall s. ST s Bool. The variable v could be of type forall s. MutVar s Bool, in which case all of runST (readVar v) typechecks. readVar v can't have the type (forall s. ST s Bool), because v must have been created by newVar. So, (newVar True = \v - readVar v) has the type (forall s. ST s Bool), but the subexpression (readVar v) has the type ST hiddenState Bool, where hiddenState is constrained to match the same state as was used by newVar and bind (=). Decoding into System F might make this more explicit: newVar :: forall t s. t - ST s (MutVar s t) readVar :: forall t s. MutVar s t - ST s t bind :: forall a b s. ST s a - (a - ST s b) - ST s b Then the expression is: /\s - bind @(MutVar s Bool) @Bool @s (newVar @Bool @s True) (\(v :: MutVar s Bool) - readVar @Bool @s v) (where /\ is a type-level lambda, and @ is used for type-level application, that is, to remove one layer of forall from a type.) Note that there is no way to turn the insides of that final lambda expression into something that uses any s without getting something of type forall s. MutVar s Bool. But there's no way to do so because newVar only returns results of type forall s. ST s (MutVar s Bool); then s is constrained to match during the binding application. Then, looking at the type of runST: forall t. (forall s. ST s t) - t, you see that runST must be passed an argument that has a type level lambda for s, saying that runST gets to choose the type s used to call it. In particular, in GHC I believe that s is always instantiated with RealWorld# when runST uses its argument, but you never get to see that. runST is just unsafePerformIO made safe by making the Real World hidden in the forall so that it can't escape. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The wheather is ⊥
The temperature is now NaN°: http://traviswalters.net/?p=58 -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The wheather is ⊥
Is that really cold or really hot? On Sun, Feb 15, 2009 at 11:27 PM, Henk-Jan van Tuyl hjgt...@chello.nlwrote: The temperature is now NaN°: http://traviswalters.net/?p=58 -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need some ideas to map XML Schema types to Haskell types
Hi, I need to work with a web service that has a few thousand types in its schema. I am trying to automate the generation of data types and serializers from the schema. My first thought was to map each data type to a Haskell record and generate pickle methods thereafter for serialziation/deserialization. However, I am seeing a few challenges in mapping Schema types to Haskell records. First issue is the naming conflicts with record fields. If the number of types were smaller, I could have manually mangled the name with a unique prefix. Using a type class for shared name fields seems like an option but it looks like quite a bit of work. Is there any other technique I can use? Second issue is with capturing the Schema type hierarchy. Is there any way to relate types? If not, what would be a good technique to represent type hierarchies? Thanks, Praki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The wheather is ⊥
It depends whether that's NaN ºC or NaN ºF. 2009/2/15 Fraser Wilson blancoli...@gmail.com: Is that really cold or really hot? On Sun, Feb 15, 2009 at 11:27 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: The temperature is now NaN°: http://traviswalters.net/?p=58 -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ 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] ANNOUNCE: pqueue-mtl, stateful-mtl
I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? More serious question: The issue of nondeterministic branching and the State monad is something that's occurred to me previously. Do I understand correctly that this would require use of an arrow transformer, rather than a monad? For a generic State monad, that would be something like newtype StateArrow a x y = SA (a (s, x) (s,y)) and then StateArrow (Kleisli []) x y translates into approximately (s, x) - [(s, y)], as desired? Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 4:06 PM, Reid Barton rwbar...@math.harvard.eduwrote: On Sun, Feb 15, 2009 at 09:59:28PM -, Sittampalam, Ganesh wrote: Stateful-mtl provides an ST monad transformer, Is this safe? e.g. does it work correctly on [], Maybe etc? If not this should be flagged very prominently in the documentation. It is not safe: it has the same problem as the STMonadTrans package, discussed recently here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016554.html The following code demonstrates that STT violates referential transparency: import Control.Monad import Data.STRef import Control.Monad.Trans import Control.Monad.ST.Trans data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving Show instance Monad Tree where return = Leaf Leaf a = k = k a Branch l r = k = Branch (l = k) (r = k) foo :: STT s Tree Integer foo = do x - liftST $ newSTRef 0 y - lift (Branch (Leaf 1) (Leaf 2)) when (odd y) (liftST $ writeSTRef x y) liftST $ readSTRef x main :: IO () main = do print $ runSTT foo let Branch _ (Leaf x) = runSTT foo print x outputting: Branch (Leaf 1) (Leaf 1) 0 Demanding the value in the left Leaf affects the value seen in the right Leaf. Regards, Reid ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Peter Verswyvelen schrieb: I'm having trouble understanding the explanation of the meaning of the signature of runST at http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types Is this one better http://haskell.org/haskellwiki/Monad/ST ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Sun, 15 Feb 2009, Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? I assume that ST must always be the most inner monad, like IO. Is this a problem in an application?___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Well, it makes me sad, I guess. pqueue-mtl provides an array-backed heap monad transformer that is supposed to keep its own ST thread, if only for the sake of retaining a purely functional interface without any externally visible forall'd types, which is perfectly fine in most cases, but I'd have to think about whether or not it'd remain referentially transparent if the ST thread were only visible to a very tightly encapsulated set of commands (i.e. priority queue operations). Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 5:33 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 15 Feb 2009, Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? I assume that ST must always be the most inner monad, like IO. Is this a problem in an application? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
2009/2/15 Brandon S. Allbery KF8NH allb...@ece.cmu.edu On 2009 Feb 15, at 11:50, Peter Verswyvelen wrote: I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? You could think about it as playing a dirty trick on the typechecker. But if you don't want to, there's another way to think about it. I'm still working on this interpretation, so be gentle :-) Think of the s in ST s a not as a type, but as itself a state; eg. a map from keys to values and a free list of fresh keys. This is the initial state of the computation, which ST transforms. Then runST says: runST :: (forall s. ST s a) - a If a computation works on every initial state, we can extract the value. Since it works for every initial state, it must not depend on it, and thus the computation's value is well-defined. Something like that. I think using existential types as regions is more essential than a dirty trick, and I advocate trying to interpret it in a semantically well-defined way. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
You can roll your own pure STT monad, at the cost of performance: -- Do not export any of these constructors, just the types STT and STTRef. data W = forall a. W !a data Heap s = Heap !Int !(IntMap W) newtype STT s m a = STT (StateT (Heap s) m a) deriving (Monad, MonadTrans, MonadIO, insert other stuff here, but not MonadState) newtype STTRef s a = Ref Int liftState :: (MonadState s m) = (s - (a,s)) - m a liftState f = do (a, s') - liftM f get put s' return a newSTTRef :: forall s m a. a - STT s m a newSTTRef a = STT $ liftState go where go (Heap sz m) = (Ref sz, Heap (sz+1) (insert sz (W a) m) readSTTRef :: forall s m a. STTRef s a - STT s m a readSTTRef (Ref n) = STT $ liftM go get where go (Heap _ m) = case lookup n m of Just (~(W a)) - unsafeCoerce a _ - error impossible: map lookup failed. writeSTTRef :: forall s m a. STTRef s a - a - STT s m () writeSTTRef (Ref n) a = STT $ modify go where go (Heap sz m) = Heap sz (insert n (W a) m) -- forall s. here makes unsafeCoerce in readSTTRef safe. Otherwise references could escape and break unsafeCoerce. runSTT :: (forall s. STT s m a) - m a runSTT (STT m) = evalStateT m (Heap 0 empty) instance (MonadState s m) = MonadState s (STT st m) where get = lift get put = lift . put modify = lift . modify Unfortunately, you lose garbage collection on referenced data since it's all stored in an IntMap. Is there a way to solve this problem, perhaps using some form of weak reference? Ideally you'd like to be able to find that all references to a particular Ref have been GC'd so that you can reuse that Ref index. Otherwise eventually the IntMap will fill up if you keep allocating references and throwing them away. -- ryan 2009/2/15 Louis Wasserman wasserman.lo...@gmail.com: Well, it makes me sad, I guess. pqueue-mtl provides an array-backed heap monad transformer that is supposed to keep its own ST thread, if only for the sake of retaining a purely functional interface without any externally visible forall'd types, which is perfectly fine in most cases, but I'd have to think about whether or not it'd remain referentially transparent if the ST thread were only visible to a very tightly encapsulated set of commands (i.e. priority queue operations). Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 5:33 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 15 Feb 2009, Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? I assume that ST must always be the most inner monad, like IO. Is this a problem in an application? ___ 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] Parameterized monad transformers
Howdy y'all!
I was reading sigfpe's Beyond Monads post
(http://blog.sigfpe.com/2009/02/beyond-monads.html) about parameterized monads.
Great post, makes you go: this is so elegant and simple, why didn't I think of that?
Anyway, I was wondering whether those monads have corresponding transformers, and
if so, what they look like and what they are good for? Is there any weight to the
idea at all?
I don't know much about monad transformer theory, but I do imagine that for
transformers to be useful, they have to be stackable, so the underlying monad of a
parameterized monad also has to be a parameterized monad. I asked around in
#haskell and ski_ and I had a couple of ideas exploring the concept (although he
did most of the exploring, I just carried his luggage).
Seeing how parameterized monads are gotten by just loosening some restrictions on
normal ones and drawing then parallels between them, I think the same methodology
could be applied to transformers.
So there should be a transformer version t of a parameterized monad m and a
lifting operation plift that lifts m to t. At first I did what sigfpe did with
non-transformer monads, which was to just implement the appropriate functions for
the more general monads and see what GHCI tells us about the type. I first thought
about having a parameterized StateT, PStateT:
newtype PStateT m s1 s2 a = PStateT { runPStateT :: s1 - m (a, s2) }
along with a lifting operation
plift :: (PMonad m) = m s1 s2 a - t (m s1 s2) s3 s3 a
but I don't think that's cool because of the different kind of the underlying
monad. So then ski_ suggested
newtype PStateT m (s1,s1') (s2,s2') a = PStateT { runPStateT :: s1 - m s1' s2'
(Pair a s2) }
where (s1,s1') and (s2,s2') stand for the pair of types and not a (,) type
constructor with two types applied as type parameters. That's why the pair in the
result is represented as Pair a s2. Anyway, s1' and s2' represent the category
tail and head of the underlying parameterized monad. With that, the lifting
operation would have a type of
plift :: (PMonad pm) = pm s1 s2 a - t pm (s, s1) (s, s2) a
basically I'm just wondering how you guys think the transformer versions of
parameterized monads work and what their types should be. And if you think they're
feasible at all. So basically just talk about parameterized monad transformers here :]
Cheerio!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
The module I put together already has everything I'd need to do it in terms
of an IntMap with much less work than that -- the generic MonadArray type
class has implementations both in terms of ST and in terms of an IntMap
already. Only three changes in the Heap implementation would be needed: two
changes from runArrayT_ 16 to evalIntMapT, and one change of ArrayT to
IntMapT. (Here ArrayT is backed by an STT transformer.)
newtype HeapT e m a = HeapT {execHeapT :: ArrayT e (StateT Int m) a}
deriving (Monad, MonadReader r, MonadST s, MonadWriter w, MonadFix, MonadIO)
-- | Runs an 'HeapT' transformer starting with an empty heap.
runHeapT :: (Monad m, Ord e) = HeapT e m a - m a
runHeapT m = evalStateT (runArrayT_ 16 (execHeapT m)) 0
But I'm still not entirely convinced that the original STT monad with all
its illegal behavior, hidden from the user, couldn't be used internally by
HeapT without exposing non-referential-transparency -- I'm still thinking on
that problem. (Perhaps it'd be useful to ask, how would this purely
functional implementation of HeapT behave when used as a drop-in replacement
for the STT-backed HeapT?)
Originally I said that I was inferring that the problem with an ST
transformer was that it allowed access to mutable references. If that's
true, can a priority queue be used to simulate an STRef? If so, wouldn't
that imply (rather elegantly, in fact) that an STT-backed heap transformer
would violate referential transparency. (Would the single-threaded array
transformer backing HeapT fail in that fashion as well?)
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 6:15 PM, Ryan Ingram ryani.s...@gmail.com wrote:
You can roll your own pure STT monad, at the cost of performance:
-- Do not export any of these constructors, just the types STT and STTRef.
data W = forall a. W !a
data Heap s = Heap !Int !(IntMap W)
newtype STT s m a = STT (StateT (Heap s) m a) deriving (Monad,
MonadTrans, MonadIO, insert other stuff here, but not MonadState)
newtype STTRef s a = Ref Int
liftState :: (MonadState s m) = (s - (a,s)) - m a
liftState f = do
(a, s') - liftM f get
put s'
return a
newSTTRef :: forall s m a. a - STT s m a
newSTTRef a = STT $ liftState go where
go (Heap sz m) = (Ref sz, Heap (sz+1) (insert sz (W a) m)
readSTTRef :: forall s m a. STTRef s a - STT s m a
readSTTRef (Ref n) = STT $ liftM go get where
go (Heap _ m) = case lookup n m of
Just (~(W a)) - unsafeCoerce a
_ - error impossible: map lookup failed.
writeSTTRef :: forall s m a. STTRef s a - a - STT s m ()
writeSTTRef (Ref n) a = STT $ modify go where
go (Heap sz m) = Heap sz (insert n (W a) m)
-- forall s. here makes unsafeCoerce in readSTTRef safe. Otherwise
references could escape and break unsafeCoerce.
runSTT :: (forall s. STT s m a) - m a
runSTT (STT m) = evalStateT m (Heap 0 empty)
instance (MonadState s m) = MonadState s (STT st m) where
get = lift get
put = lift . put
modify = lift . modify
Unfortunately, you lose garbage collection on referenced data since
it's all stored in an IntMap. Is there a way to solve this problem,
perhaps using some form of weak reference? Ideally you'd like to be
able to find that all references to a particular Ref have been GC'd so
that you can reuse that Ref index. Otherwise eventually the IntMap
will fill up if you keep allocating references and throwing them away.
-- ryan
2009/2/15 Louis Wasserman wasserman.lo...@gmail.com:
Well, it makes me sad, I guess. pqueue-mtl provides an array-backed heap
monad transformer that is supposed to keep its own ST thread, if only for
the sake of retaining a purely functional interface without any
externally
visible forall'd types, which is perfectly fine in most cases, but I'd
have
to think about whether or not it'd remain referentially transparent if
the
ST thread were only visible to a very tightly encapsulated set of
commands
(i.e. priority queue operations).
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 5:33 PM, Henning Thielemann
lemm...@henning-thielemann.de wrote:
On Sun, 15 Feb 2009, Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use
of STT -- despite being
pretty much a State monad on the inside -- allows access to things like
mutable references?
I assume that ST must always be the most inner monad, like IO. Is this a
problem in an application?
___
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] ANNOUNCE: pqueue-mtl, stateful-mtl
Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? That's exactly the problem. The essential reason for ST's existence are STRefs which allow mutability. With only a single path of execution[1] the destructive mutability can't be observed (i.e. ST is observationally equivalent to State which performs non-destructive updates). However once nondeterminism, concurrency (not parallelism), or backtracking enter the picture the bisimilarity goes away and it's possible to observe the mutations and break referential transparency. [1] An intentionally vague phrase. Abstractly speaking nondeterminism, concurrency, and backtracking all amount to existing simultaneously at multiple points in the program with each of these points moving at an independent rate. Since they're independent it's possible for one thread to make a change and then have another move to see it. With only a single execution point it's not possible to tell what your history is, and so you can't know if it changes out from behind you. More serious question: The issue of nondeterministic branching and the State monad is something that's occurred to me previously. Do I understand correctly that this would require use of an arrow transformer, rather than a monad? Nope. You can just use StateT over list or Logic[2] and everything works out. Since the state of State/StateT is a persistent data structure[3] it's fine to hold onto copies of it from many points along it's update history. With a nondeterminism monad you essentially just hold onto copies of the state at each choice point, thus it's available whenever you need to backtrack. [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logict [3] Whereas using STRefs or similar would enable creating ephemeral data structures more familiar to imperative programmers. By their nature, if we wanted to keep copies of these throughout their mutation history, then we'd have to clone the data structure so that future mutations don't affect the old copy. Or equivalently, use a copy-on-write scheme. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock Markup
On 15 Feb 2009, at 5:45 am, Wolfgang Jeltsch wrote: So you mean a language which * directly corresponds to a subset of MathML (and is therefore easily convertible into sensible MathML) * is at the same time valid TeX source which can be processed by TeX based on a few macro definitions (like \mrow) Yes. The thing is clearly doable in principle; whether it would work well in practice is another matter, of course. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Hello all,
I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad transformer
and array transformer have been removed -- I've convinced myself that a heap
transformer backed by an ST array cannot be referentially transparent -- and
the heap monad is now available only as a basic monad and not a transformer,
though it still provides priority queue functionality to any of the mtl
wrappers around it. stateful-mtl retains a MonadST typeclass which is
implemented by ST and monad transformers around it, allowing computations in
the the ST-bound heap monad to perform ST operations in its thread.
Since this discussion had largely led to the conclusion that ST can only be
used as a bottom-level monad, it would be pretty uncool if ST computations
couldn't be performed in a monad using ST internally because the ST thread
was hidden and there was no way to place ST computations 'under' the outer
monad. Anyway, it's essentially just like the MonadIO typeclass, except
with a functional dependency on the state type.
There was a question I asked that never got answered, and I'm still curious:
would an ST *arrow* transformer be valid? Arrows impose sequencing on their
operations that monads don't... I'm going to test out some ideas, I think.
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 6:45 PM, Louis Wasserman
wasserman.lo...@gmail.comwrote:
The module I put together already has everything I'd need to do it in terms
of an IntMap with much less work than that -- the generic MonadArray type
class has implementations both in terms of ST and in terms of an IntMap
already. Only three changes in the Heap implementation would be needed: two
changes from runArrayT_ 16 to evalIntMapT, and one change of ArrayT to
IntMapT. (Here ArrayT is backed by an STT transformer.)
newtype HeapT e m a = HeapT {execHeapT :: ArrayT e (StateT Int m) a}
deriving (Monad, MonadReader r, MonadST s, MonadWriter w, MonadFix, MonadIO)
-- | Runs an 'HeapT' transformer starting with an empty heap.
runHeapT :: (Monad m, Ord e) = HeapT e m a - m a
runHeapT m = evalStateT (runArrayT_ 16 (execHeapT m)) 0
But I'm still not entirely convinced that the original STT monad with all
its illegal behavior, hidden from the user, couldn't be used internally by
HeapT without exposing non-referential-transparency -- I'm still thinking on
that problem. (Perhaps it'd be useful to ask, how would this purely
functional implementation of HeapT behave when used as a drop-in replacement
for the STT-backed HeapT?)
Originally I said that I was inferring that the problem with an ST
transformer was that it allowed access to mutable references. If that's
true, can a priority queue be used to simulate an STRef? If so, wouldn't
that imply (rather elegantly, in fact) that an STT-backed heap transformer
would violate referential transparency. (Would the single-threaded array
transformer backing HeapT fail in that fashion as well?)
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 6:15 PM, Ryan Ingram ryani.s...@gmail.com wrote:
You can roll your own pure STT monad, at the cost of performance:
-- Do not export any of these constructors, just the types STT and STTRef.
data W = forall a. W !a
data Heap s = Heap !Int !(IntMap W)
newtype STT s m a = STT (StateT (Heap s) m a) deriving (Monad,
MonadTrans, MonadIO, insert other stuff here, but not MonadState)
newtype STTRef s a = Ref Int
liftState :: (MonadState s m) = (s - (a,s)) - m a
liftState f = do
(a, s') - liftM f get
put s'
return a
newSTTRef :: forall s m a. a - STT s m a
newSTTRef a = STT $ liftState go where
go (Heap sz m) = (Ref sz, Heap (sz+1) (insert sz (W a) m)
readSTTRef :: forall s m a. STTRef s a - STT s m a
readSTTRef (Ref n) = STT $ liftM go get where
go (Heap _ m) = case lookup n m of
Just (~(W a)) - unsafeCoerce a
_ - error impossible: map lookup failed.
writeSTTRef :: forall s m a. STTRef s a - a - STT s m ()
writeSTTRef (Ref n) a = STT $ modify go where
go (Heap sz m) = Heap sz (insert n (W a) m)
-- forall s. here makes unsafeCoerce in readSTTRef safe. Otherwise
references could escape and break unsafeCoerce.
runSTT :: (forall s. STT s m a) - m a
runSTT (STT m) = evalStateT m (Heap 0 empty)
instance (MonadState s m) = MonadState s (STT st m) where
get = lift get
put = lift . put
modify = lift . modify
Unfortunately, you lose garbage collection on referenced data since
it's all stored in an IntMap. Is there a way to solve this problem,
perhaps using some form of weak reference? Ideally you'd like to be
able to find that all references to a particular Ref have been GC'd so
that you can reuse that Ref index. Otherwise eventually the IntMap
will fill up if you keep allocating references and throwing them away.
-- ryan
2009/2/15 Louis Wasserman wasserman.lo...@gmail.com:
Well, it makes me sad, I guess. pqueue-mtl provides an
Re: [Haskell-cafe] Comparison of functional dependencies and type families [was: Re: Type families not as useful over functions]
Just for the record, here a few clarifications. Expressiveness ~~ From a theoretical point of view, type families (TFs) and functional dependencies (FDs) are equivalent in expressiveness. There is nothing that you can do in one and that's fundamentally impossible in the other. See also Related Work in http://www.cse.unsw.edu.au/~chak/papers/SPCS08.html . In fact, you could give a translation from one into the other. Haskell ~~~ This simple equivalence starts to break down when you look at the use of the two language features in Haskell. This is mainly because there are some syntactic contexts in Haskell, where you can have types, but no class contexts. An example, are newtype definitions. Implementation in GHC ~ The situation becomes quite a bit more tricky once you look at the interaction with other type system features and GHC's particular implementation of FDs and TFs. Here the highlights: * GADTs: - GADTs and FDs generally can't be mixed (well, you can mix them, and when a program compiles, it is type correct, but a lot of type correct programs will not compile) - GADTs and TFs work together just fine * Existential types: - Don't work properly with FDs; here is an example: class F a r | a - r instance F Bool Int data T a = forall b. F a b = MkT b add :: T Bool - T Bool - T Bool add (MkT x) (MkT y) = MkT (x + y) -- TYPE ERROR - Work fine with TFs; here the same example with TFs type family F a type instance F Bool = Int data T a = MkT (F a) add :: T Bool - T Bool - T Bool add (MkT x) (MkT y) = MkT (x + y) (Well, strictly speaking, we don't even need an existential here, but more complicated examples are fine, too.) * Type signatures: - GHC will not do any FD improvement in type signatures; here an example that's rejected as a result (I assume Hugs rejects that, too): class F a r | a - r instance F Bool Int same :: F Bool a = a - Int same = id -- TYPE ERROR (You may think that this is a rather artificial example, but firstly, this idiom is useful when defining abstract data types that have a type dependent representation type defined via FDs. And secondly, the same situation occurs, eg, when you define an instance of a type class where one method has a class context that contains a type class with an FD.) - TFs will be normalised (ie, improved) in type signatures; the same example as above, but with a TF: type family F a type instance F Bool = Int same :: F Bool - Int same = id * Overlapping instances: - Type classes with FDs may use overlapping instances (I conjecture that this is only possible, because GHC does not improve FDs in type signatures.) - Type instances of TFs cannot use overlapping instances (this is important to ensure type safety) It's a consequence of this difference that closed TFs are a features that is requested more often than closed classes with FDs. Manuel PS: Associated types are just syntactic sugar for TFs, there is nothing that you can do with them that you cannot do with TFs. Moreover, it is easy to use type families for bijective type functions; cf. http://www.haskell.org/pipermail/haskell-cafe/2009-January/053696.html . (This follows of course from the equivalence of expressiveness of TFs and FDs.) Ahn, Ki Yung: My thoughts on type families: 1) Type families are often too open. I causes rigid variable type error messages because when I start writing open type functions, I often realize that what I really intend is not truly open type functions. It happens a lot that I had some assumptions on the arguments or the range of the type function. Then, we need help of type classes to constrain the result of open type functions. For example, try to define HList library using type families instead of type classes with functional dependencies. One will soon need some class constraints. Sometimes, we can use associated type families, but many times it may become tedious when there are multiple arguments and result have certain constraints so that we might end up associating/splitting them over multiple type classes. In such cases, it may be more simple working with functional dependencies alone, rather than using both type classes and type families. I wish we had closed kinds so that we can define closed type functions as well as open type functions. 2) Type families are not good when we need to match types back and forth (e.g. bijective functions), or even multiple ways. We need the help of functional dependencies for these relational definitions. I know that several people are working on the unified implementation for both type families and functional dependencies. Once GHC have common background implementation, type families will truly be syntactic
Re: [Haskell-cafe] Interactive debugging?
On 2009 Feb 15, at 15:22, Colin Paul Adams wrote: Can this be done with Haskell? In particular, I'm using ghc 6.10.1. Can I get symbols for use with gdb, for instance gdb would be extremely painful; the flow of execution in lazy languages is unusual. ghci from 6.8.1 on has an interactive debugger built in; it's still evolving though. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote: Hello all, I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad transformer and array transformer have been removed -- I've convinced myself that a heap transformer backed by an ST array cannot be referentially transparent -- and the heap monad is now available only as a basic monad and not a transformer, though it still provides priority queue functionality to any of the mtl wrappers around it. stateful-mtl retains a MonadST typeclass which is implemented by ST and monad transformers around it, allowing computations in the the ST-bound heap monad to perform ST operations in its thread. Since this discussion had largely led to the conclusion that ST can only be used as a bottom-level monad, it would be pretty uncool if ST computations couldn't be performed in a monad using ST internally because the ST thread was hidden and there was no way to place ST computations 'under' the outer monad. Anyway, it's essentially just like the MonadIO typeclass, except with a functional dependency on the state type. There was a question I asked that never got answered, and I'm still curious: would an ST *arrow* transformer be valid? Arrows impose sequencing on their operations that monads don't... I'm going to test out some ideas, I think. Your proposed type: State (Kleisli []) x y = (s, x) - [(s, y)] is (roughly) isomorphic to: x - StateT s [] y = x - s - [(s, y)] The problem with an ST transformer is that the state parameter needs to be used linearly, because that's the only condition under which the optimization of mutable update is safe. ST ensures this by construction, as opposed to other languages (Clean) that have type systems that can express this kind of constraint directly. However, with STT, whether the state parameter is used linearly is a function of the wrapped monad. You'd have to give a more fleshed out version of your proposed state arrow transformer, but off the top of my head, I'm not sure it'd be any better. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: spacepart-0.1.0.0 (was called data-spacepart)
0.1.0.0 - Renamed Math.Geometry to Data.SpacePart.AABB - Renamed Data.QuadTree to Data.SpacePart.QuadTree - Added Data.SpacePart.QuadTree.query. Returns all elements that intersect a given boundary. - The inclusive nature of the boundary's min extent should take precedence of the exclusive nature of the max extent. Before this change many of the tests failed when boundaries of 0 area were involved. One case that did not work was constructing a quadtree containing elements of 0 area. This change corrected this. The tests all_elements_inserted_query_prop and element_bounds_query_is_element_prop still fail if any element involved is of 0 area. - Cannot create quadtrees with initial bounds of 0 area. - Removed requirement on elements being an instance of the Intersectable class. The only required instance is of Data.SpacePart.AABB.HasBoundary. - Changed package name to spacepart instead of data-spacepart. The last release of data-spacepart used a data based version number. This version number policy did not work well with the standard package version policy. - Added some QuickCheck based checks. Run with test/run_verify - Cleaned up the module exports. Cheers, Corey O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow transformer has the same problem. I realized this after I sent the last message -- the point is that at any particular point, intuitively there should be exactly one copy of a State# s for each state thread, and it should never get duplicated; allowing other monads or arrows to hold a State# s in any form allows them to hold more than one, violating that goal. I'm not entirely convinced yet that there *isn't* some really gorgeous type system magic to fix this issue, like the type-system magic that motivates the type of runST in the first place, but that's not an argument that such magic exists...it's certainly an interesting topic to mull. Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com wrote: On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote: Hello all, I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad transformer and array transformer have been removed -- I've convinced myself that a heap transformer backed by an ST array cannot be referentially transparent -- and the heap monad is now available only as a basic monad and not a transformer, though it still provides priority queue functionality to any of the mtl wrappers around it. stateful-mtl retains a MonadST typeclass which is implemented by ST and monad transformers around it, allowing computations in the the ST-bound heap monad to perform ST operations in its thread. Since this discussion had largely led to the conclusion that ST can only be used as a bottom-level monad, it would be pretty uncool if ST computations couldn't be performed in a monad using ST internally because the ST thread was hidden and there was no way to place ST computations 'under' the outer monad. Anyway, it's essentially just like the MonadIO typeclass, except with a functional dependency on the state type. There was a question I asked that never got answered, and I'm still curious: would an ST *arrow* transformer be valid? Arrows impose sequencing on their operations that monads don't... I'm going to test out some ideas, I think. Your proposed type: State (Kleisli []) x y = (s, x) - [(s, y)] is (roughly) isomorphic to: x - StateT s [] y = x - s - [(s, y)] The problem with an ST transformer is that the state parameter needs to be used linearly, because that's the only condition under which the optimization of mutable update is safe. ST ensures this by construction, as opposed to other languages (Clean) that have type systems that can express this kind of constraint directly. However, with STT, whether the state parameter is used linearly is a function of the wrapped monad. You'd have to give a more fleshed out version of your proposed state arrow transformer, but off the top of my head, I'm not sure it'd be any better. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: spacepart-0.1.0.0 (was called data-spacepart)
(Omitted some useful information from original emails. Oops!) Space partition data structures. Currently only a quadtree. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/spacepart On Sun, Feb 15, 2009 at 7:28 PM, Corey O'Connor coreyocon...@gmail.com wrote: 0.1.0.0 - Renamed Math.Geometry to Data.SpacePart.AABB - Renamed Data.QuadTree to Data.SpacePart.QuadTree - Added Data.SpacePart.QuadTree.query. Returns all elements that intersect a given boundary. - The inclusive nature of the boundary's min extent should take precedence of the exclusive nature of the max extent. Before this change many of the tests failed when boundaries of 0 area were involved. One case that did not work was constructing a quadtree containing elements of 0 area. This change corrected this. The tests all_elements_inserted_query_prop and element_bounds_query_is_element_prop still fail if any element involved is of 0 area. - Cannot create quadtrees with initial bounds of 0 area. - Removed requirement on elements being an instance of the Intersectable class. The only required instance is of Data.SpacePart.AABB.HasBoundary. - Changed package name to spacepart instead of data-spacepart. The last release of data-spacepart used a data based version number. This version number policy did not work well with the standard package version policy. - Added some QuickCheck based checks. Run with test/run_verify - Cleaned up the module exports. Cheers, Corey O'Connor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help needed with apache config for hackage
On Fri, 2009-02-13 at 22:39 +1100, George Pollard wrote: RewriteRule ^packages/archive/[^/]+/[^/]+/(.+)$ - [env=pkgname:$1] This should actually be more constrained since (as I've just noticed) more than just packages are under this path :) Perhaps: RewriteRule ^packages/archive/[^/]+/[^/]+/([^/]+\\.tar\\.gz)$ - [env=pkgname:$1] signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Amazing
Hi Peter, I'm delighted to hear about your successes with Haskell programming! I suspect that parametric polymorphism has a lot to do with phenomenon of works-when-it-compiles. The more polymorphic a signature is, the fewer the possible type-correct definitions. Luckily, the definition that works is one of the few type-correct ones. As John Reynolds and then Phil Wadler showed, some useful properties necessarily hold purely as a consequence of the polymorphic type, regardless of the implementation. (See Theorems for free.) - Conal 2009/2/14 Peter Verswyvelen bugf...@gmail.com One of the things I liked a lot when working with C# was that as soon as my code compiled, it usually worked after an iteration of two.At least if we forget about the nasty imperative debugging that is needed after a while because of unanticipated and unchecked runtime side effects. After heaving read about Haskell and having written some small programs for the last year or so, I'm now finally writing a bigger program with it. It is not so easy yet since learning a language and trying to reach a deadline at the same time is hard :) However, it is just amazing that whenever my Haskell program compiles (which to be fair can take a while for an average Haskeller like me ;-), it just... works! I have heard rumors that this was the case, but I can really confirm it. A bit hurray for strong typing! (and if you don't like it, you can still use Dynamic and Typeable ;-) ___ 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] Looking for pointfree version
And then to down = mconcat [downPar, downNew, downTrans] Which is pretty cute considering that the original formulation is equivalent to and a tiny tweak away from down p = mconcat [downPar p, downNew p, downTrans p] Hooray for Monoid! - Conal On Mon, Feb 9, 2009 at 6:31 AM, Wouter Swierstra w...@cs.nott.ac.uk wrote: snip How about using Data.Monoid: down = downPar `mappend` downNew `mappend` downTrans Wouter ___ 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
