Re: [Haskell-cafe] ANNOUNCE: set-monad
Hi George, thanks for your detailed reply. George Giorgidze wrote: The key to the approach used in set-monad is to make progress with the evaluation of the unconstrained constructors (i.e., Return, Bind, Zero and Plus) without using constrained set-specific operations. It turns out that for several cases one can progress with the evaluation without duplicating f (evaluation relies on monoid laws, Plus is associative and Zero is left and right identity of Plus). I have pushed those optimisations to the repo. These optimisations also cover your example. Cool. In your email, you have also asked: I suspect that I can achieve similar results by using the list monad and converting to a set in the very end. In what situations can I benefit from set-monad? Sometimes set is a more appropriate data structure than list. [...] Of course. But I was wondering whether something like set-monad could be implemented with newtype Set a = Set [a] instead of data Set a = Prim ... | Return ... | Bind ... | ... Both approaches can offer the same interface, but now I think I see two reasons why the latter is more efficient than the former: (1) It allows to use set-operations when an Ord is known, for example, when the user calls union, and (2) It allows optimizations like you describe above. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP 2012 programming contest
jPlease consider putting together a team/encourage your students, friends, colleagues to put together a team for the ICFP 2012 programming contest. Entries can be made in ANY LANGUAGE (including one of your own invention) as long as the submitted program can be run by the judges on a standard Linux environment with no network connection (sorry, Vixo!). The competition will run from 1200 UTC on July 13th for 72 hours. There will also be a lightning (24 hour) division for those who can't dedicate a full 72 hours to the contest. This is an open contest. Anybody may participate except for the contest organisers and members of the same group as the the contest chairs. http://icfpcontest2012.wordpress.com/ Did we mention that the contest is sponsored by Facebook and there will be cash prizes (and no entry fee)! What do you have to lose? Book your holiday time and pizza deliveries now! Best Wishes, Kevin Kevin Hammond, Professor of Computer Science, University of St Andrews T: +44-1334 463241 F: +44-1334-463278W: http://www.cs.st-andrews.ac.uk/~kh In accordance with University policy on electronic mail, this email reflects the opinions of the individual concerned, may contain confidential or copyright information that should not be copied or distributed without permission, may be of a private or personal nature unless explicitly indicated otherwise, and should not under any circumstances be taken as an official statement of University policy or procedure (see http://www.st-and.ac.uk). The University of St Andrews is a charity registered in Scotland : No SC013532 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question on proper use of Data.IORef
Hi experts, I fear I don't understand how to properly use *Data.IORef*. I wrote the following code: 1 -- Testing Data.IORef 2 module Main where 3 4 import Data.IORef 5 6 bump :: IORef Int - IO() 7 bump theRef = do 8 tmp - readIORef theRef 9 let tmp2 = tmp + 1 10 writeIORef theRef tmp2 11 12 main = do 13 let theValue = 1 14 print theValue 15 theValueRef - newIORef theValue 16 bump theValueRef 17 return theValue and got this, in ghci: *Main :load test2.hs [1 of 1] Compiling Main ( test2.hs, interpreted ) Ok, modules loaded: Main. *Main main 1 *1* I was expecting this: *Main :load test2.hs [1 of 1] Compiling Main ( test2.hs, interpreted ) Ok, modules loaded: Main. *Main main 1 *2* Can anyone help me understand what I'm doing wrong? Thanks! -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on proper use of Data.IORef
theValueRef isn't a pointer to theValue that you can use to somehow change theValue (which is immutable). theValueRef is a reference to a box that contains a totally separate, mutable value. When you use newIORef to create theValueRef, it's *copying* theValue into the box. When you mutate theValueRef, you're mutating the value inside the box - theValue remains unchanged. Cheers, Adam On 22 June 2012 11:30, Captain Freako capn.fre...@gmail.com wrote: Hi experts, I fear I don't understand how to properly use *Data.IORef*. I wrote the following code: 1 -- Testing Data.IORef 2 module Main where 3 4 import Data.IORef 5 6 bump :: IORef Int - IO() 7 bump theRef = do 8 tmp - readIORef theRef 9 let tmp2 = tmp + 1 10 writeIORef theRef tmp2 11 12 main = do 13 let theValue = 1 14 print theValue 15 theValueRef - newIORef theValue 16 bump theValueRef 17 return theValue and got this, in ghci: *Main :load test2.hs [1 of 1] Compiling Main ( test2.hs, interpreted ) Ok, modules loaded: Main. *Main main 1 *1* I was expecting this: *Main :load test2.hs [1 of 1] Compiling Main ( test2.hs, interpreted ) Ok, modules loaded: Main. *Main main 1 *2* Can anyone help me understand what I'm doing wrong? Thanks! -db ___ 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] Question on proper use of Data.IORef
On Fri, Jun 22, 2012 at 5:30 PM, Captain Freako capn.fre...@gmail.com wrote: 12 main = do 13 let theValue = 1 14 print theValue 15 theValueRef - newIORef theValue 16 bump theValueRef 17 return theValue theValue is a plain old immutable Haskell variable. newIORef creates an IORef whose initial value is equal to the argument; it doesn't create a pointer to the value or something like that. Change return theValue to readIORef theValueRef to extract the changed value in the IORef. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on proper use of Data.IORef
Okay, I get it now. Thanks to all of you for your quick replies! So, here's what I need to do: 1. My Haskell code gets called by a higher level C function and asked to initialize itself. 2. As part of that initialization, I'm expected to return a pointer to an instance of a particular data structure, which gets created/initialized in Haskell. 3. I create a stable pointer to a data structure instance, using * newStablePtr*, and return that pointer to the calling C function. 4. The same C function then, at a later time, calls a different function in my Haskell code, sending it that very same pointer, and expects that code to modify the data structure pointed to, in place. So, I wrote some code that looks like this: secondFunction :: StablePtr DataStructure - IO () secondFunction dsPtr = do ds - deRefStablePtr dsPtr theRef - newIORef ds writeIORef theRef newDs which, of course, didn't work, because I didn't understand the true nature of IORef. *So, my question is: How do I do this? That is, how do I modify, in place, a data structure, which I originally created and made stable, using a pointer to that structure, which is being passed back to me, by the higher level C function that is calling me?* Thanks, all! -db On Fri, Jun 22, 2012 at 8:43 AM, Max Rabkin max.rab...@gmail.com wrote: On Fri, Jun 22, 2012 at 5:30 PM, Captain Freako capn.fre...@gmail.com wrote: 12 main = do 13 let theValue = 1 14 print theValue 15 theValueRef - newIORef theValue 16 bump theValueRef 17 return theValue theValue is a plain old immutable Haskell variable. newIORef creates an IORef whose initial value is equal to the argument; it doesn't create a pointer to the value or something like that. Change return theValue to readIORef theValueRef to extract the changed value in the IORef. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on proper use of Data.IORef
On Fri, Jun 22, 2012 at 11:18 AM, Captain Freako capn.fre...@gmail.com wrote: Okay, I get it now. Thanks to all of you for your quick replies! So, here's what I need to do: My Haskell code gets called by a higher level C function and asked to initialize itself. As part of that initialization, I'm expected to return a pointer to an instance of a particular data structure, which gets created/initialized in Haskell. I create a stable pointer to a data structure instance, using newStablePtr, and return that pointer to the calling C function. The same C function then, at a later time, calls a different function in my Haskell code, sending it that very same pointer, and expects that code to modify the data structure pointed to, in place. So, I wrote some code that looks like this: secondFunction :: StablePtr DataStructure - IO () secondFunction dsPtr = do ds - deRefStablePtr dsPtr theRef - newIORef ds writeIORef theRef newDs which, of course, didn't work, because I didn't understand the true nature of IORef. So, my question is: How do I do this? That is, how do I modify, in place, a data structure, which I originally created and made stable, using a pointer to that structure, which is being passed back to me, by the higher level C function that is calling me? You could use a StablePtr (IORef DataStructure). Thanks, all! -db On Fri, Jun 22, 2012 at 8:43 AM, Max Rabkin max.rab...@gmail.com wrote: On Fri, Jun 22, 2012 at 5:30 PM, Captain Freako capn.fre...@gmail.com wrote: 12 main = do 13 let theValue = 1 14 print theValue 15 theValueRef - newIORef theValue 16 bump theValueRef 17 return theValue theValue is a plain old immutable Haskell variable. newIORef creates an IORef whose initial value is equal to the argument; it doesn't create a pointer to the value or something like that. Change return theValue to readIORef theValueRef to extract the changed value in the IORef. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Enum succ and pred functions throw exception
On Thu, Jun 21, 2012 at 5:36 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: It always struck me as odd that Enum doesn't extend Ord. There's a reason given for not having Bounded extend Ord, which doesn't really apply to a class having fromEnum :: a - Int. Testing whether an enum bound is at a limit is thus a bit tricky. An ordering does not typically induce a computable enumeration. For example, there are infinitely many rationals between any pair of rationals. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Enum succ and pred functions throw exception
An ordering does not typically induce a computable enumeration. For example, there are infinitely many rationals between any pair of rationals. I didn't say it was odd that Ords weren't Enums, I said that it's odd that Enums aren't Ords. It makes little or no sense to make treat rationals as Enums; the intent of enums is generally to provide *exhaustive* enumeration of a *discrete* set. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Enum succ and pred functions throw exception
I hit reply instead of reply all. Sorry Richard. On Fri, Jun 22, 2012 at 4:35 PM, o...@cs.otago.ac.nz wrote: An ordering does not typically induce a computable enumeration. For example, there are infinitely many rationals between any pair of rationals. I didn't say it was odd that Ords weren't Enums, I said that it's odd that Enums aren't Ords. You said: It always struck me as odd that Enum doesn't extend Ord. Ambiguous, at best. In any case, the order induced by the enumeration of the rationals is not compatible with the magnitude/sign order either. This is typically true. It makes little or no sense to make treat rationals as Enums; the intent of enums is generally to provide *exhaustive* enumeration of a *discrete* set. I don't see that in the documentation anywhere, and enumerable is synonymous with countable/computable (depending on the context). The usual topology on the structure has nothing to do with its enumerability. The set of pairs of positive integers is discrete under the obvious product topology. Indeed, the standard enumeration is (almost) formally equivalent to that of the positive rationals. The only difference is we aren't skipping over the diagonal. Enumerating the rationals is straight-forward. http://www.cs.ox.ac.uk/jeremy.gibbons/publications/rationals.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
