Re: [Haskell-cafe] diff implementation in haskell
Don Stewart d...@galois.com writes: Are there pure haskell implementations of diff and diff3 algorithms? http://hackage.haskell.org/package/Diff Wherein we can read: | This is an implementation of the O(ND) diff algorithm [...]. It is O(mn) | in space. At first I thought 'N' and 'M' would be the lengths of the lists, and 'D' is the number of differences, but then the space bound doesn't make sense. I tried to find the reference, but Citeseer is down (again. sigh). Anybody know what the bounds really are? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
Lyndon Maydwell maydw...@gmail.com writes: On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams colinpaulad...@googlemail.com wrote: 2009/12/7 drostin77 ml.nwgr...@gmail.com: Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) House? 'Hood? Horde? And of course, haskell.org is the Hopefully Helpful Haskell Hoard. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] diff implementation in haskell
ketil: Don Stewart d...@galois.com writes: Are there pure haskell implementations of diff and diff3 algorithms? http://hackage.haskell.org/package/Diff Wherein we can read: | This is an implementation of the O(ND) diff algorithm [...]. It is O(mn) | in space. At first I thought 'N' and 'M' would be the lengths of the lists, and 'D' is the number of differences, but then the space bound doesn't make sense. I tried to find the reference, but Citeseer is down (again. sigh). Anybody know what the bounds really are? This looks like the paper, http://www.xmailserver.org/diff2.pdf Page 2, The algorithm can be refined to use linear space, N and M appear to be the length of the sequences, D is the size of the minimum edit script. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
I take 'Hood. Er... any responses to my questions? Ketil Malde-5 wrote: Lyndon Maydwell maydw...@gmail.com writes: On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams colinpaulad...@googlemail.com wrote: 2009/12/7 drostin77 ml.nwgr...@gmail.com: Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) House? 'Hood? Horde? And of course, haskell.org is the Hopefully Helpful Haskell Hoard. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26674323.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] When are undecidables ok?
I don’t think it’s all that complicated or fragile. To resolve the constraint (C T1 T2), use the appropriate instance declaration to express it in terms of (hopefully simpler) constraints. Keep doing that. If you terminate, GHC should. Example: to resolve Eq [Int], use the instance declaration instance Eq a = Eq [a] That gives rise to the new constraint Eq Int. Use the instance declaration instance Eq Int That gives rise to no new instances. Done. If you terminate and GHC does not, write down your reasoning (ie how you resolved the instance) and send it in. [NB: There is a wrinkle for “recursive dictionaries”, described in the SYB3 paper.] Simon Well, the reasoning for the devil camp (which I admit to being firmly in[1]) is that such proofs must rely on the algorithm the compiler uses to resolve instances. You might be able to prove it, but the proof is necessarily only valid for (possibly current versions of) GHC. The typeclass resolution algorithm is not in the report, and there are several conceivable ways of of going about it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] diff implementation in haskell
Don Stewart wrote: This looks like the paper, http://www.xmailserver.org/diff2.pdf Page 2, The algorithm can be refined to use linear space, N and M appear to be the length of the sequences, D is the size of the minimum edit script. T'would be lovely to have that in the docs for the package :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
I had heard that Hoogle actually compiled any type-signatures, where as Hayoo just did a text comparison. I'm not actually sure if this is true or not though. If it is, it would mean that [q] - [r] - [(q,r)] would return zip in Hoogle, but not Hayoo. Am I right about this? On Mon, Dec 7, 2009 at 4:52 PM, drostin77 ml.nwgr...@gmail.com wrote: I take 'Hood. Er... any responses to my questions? Ketil Malde-5 wrote: Lyndon Maydwell maydw...@gmail.com writes: On Mon, Dec 7, 2009 at 2:43 PM, Colin Adams colinpaulad...@googlemail.com wrote: 2009/12/7 drostin77 ml.nwgr...@gmail.com: Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) House? 'Hood? Horde? And of course, haskell.org is the Hopefully Helpful Haskell Hoard. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26674323.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
On Mon, Dec 7, 2009 at 10:24 AM, Lyndon Maydwell maydw...@gmail.com wrote: I had heard that Hoogle actually compiled any type-signatures, where as Hayoo just did a text comparison. I'm not actually sure if this is true or not though. If it is, it would mean that [q] - [r] - [(q,r)] would return zip in Hoogle, but not Hayoo. Am I right about this? You are right: http://haskell.org/hoogle/?hoogle=[q]%20-%3E%20[r]%20-%3E%20[%28q%2Cr%29] But Hayoo searches all of hackage while Hoogle also searches a lot, but not all. If I'm searching for a function that is probably in base or containers, I use hoogle. Otherwise I use hayoo. In short: They are both very useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Insert a laziness break into strict ST
On Sun, 6 Dec 2009, Antoine Latter wrote: On Sun, Dec 6, 2009 at 5:46 PM, Henning Thielemann I hoped to get the first answer also for the second command. It seems that conversion from lazy to strict ST also removes laziness breaks. It seems that I have to stick to unsafeInterleaveIO, but I like to know, why the above method does not work. This isn't the answer you want, but there is an unsafeInterleaveST. This was a typo, I actually meant unsafeInterleaveST. So, I'm still uncertain why the conversion to lazy ST and back does not work. I feel, that I have still not understood what lazy ST actually means. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
On Monday 07 December 2009 10:24:37 Lyndon Maydwell wrote: I had heard that Hoogle actually compiled any type-signatures, where as Hayoo just did a text comparison. I'm not actually sure if this is true or not though. If it is, it would mean that [q] - [r] - [(q,r)] would return zip in Hoogle, but not Hayoo. Am I right about this? Yes, we (in Hayoo!) only do text based stuff. Is is possbile to search for signatures, but no generalization etc. is done at all. This is very primitive in Hayoo! and I really suggest using Hoogle for type searches. As for the question about a command line interface: There is nothing like that for Hayoo!, although one could easily hack something together, just using some wget-grep-cut-magic. I also have some code lying around for primitive command line searches using an offline Hayoo! index. Maybe I could get that into proper shape, given enough public demand ;) Cheers, Timo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
klondike schrieb: Henning Thielemann escribió: It seems again to me, that mixing of (programming) errors and exceptions is going on, and I assumed that the purpose of control-monad-exception is to separate them in a better way. You know, could you tell me when using head on an empty list is a programming error and when it is a exception, I have seen both cases... The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
klondike schrieb: Now comes the time when I have to show you that not every exception could be handled, IE a file not found exception when looking for the config file can be fatal and force the program to stop. But what if this is on a library? How do you suggest that the programmer knows that the File Not Found exception is due to the lack of that config file, specially when the code is badly (or not) documented. A library function that reads a config file may declare to be able to throw the exception File not found, or it may introduce a new exception Could not read Config file with an extra field for the reason, why the file could not be read. This way you can construct a call stack that helps the user (and not the programmer). Then the message reported to the user might be: Program could not be started, because Config file could not be read because Config file does not exist in dir0, dir1, dir2 but the exception handler may also decide to use a default configuration instead or ask the user, how to proceed. Anyway, such a call stack for the user requires different information than a call stack for programmer for debugging. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) Out of curiosity, how would you classify an error that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? Cheers, Greg On Dec 7, 2009, at 2:23 AM, Henning Thielemann wrote: klondike schrieb: Henning Thielemann escribió: It seems again to me, that mixing of (programming) errors and exceptions is going on, and I assumed that the purpose of control-monad-exception is to separate them in a better way. You know, could you tell me when using head on an empty list is a programming error and when it is a exception, I have seen both cases... The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do you need Windows USB in Haskell?
I don't need usb and I can't say I'm a windows user, but I'd be glad to test it since I have it on a virtual machine. In my case, installation fails on bindings-common. bindings-common fails on windows due to an old version of C library with GHC's windows version of gcc. Current version of bindings-libusb uses bindings-DSL. I'm glad that you offered to help. But usb is not supposed to work on windows yet. The windows version of the C library has been worked on recently, so, I would need someone who would follow closely this still alpha code and maybe even sugesting adaptations to libusb-1.x build system if necessary. I don't think it's fair to expect that from someone who isn't going to use the library. Thanks! Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Gregory Crosswhite schrieb: Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) Out of curiosity, how would you classify an error that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? I thought I just used this as an example in the article ... ill-formed input is clearly an exception, since it is not the fault of the compiler developer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenCL target for DPH?
Hi, Good question. I'd like to know the answer too. Cheers, Alex. On Mon, Dec 7, 2009 at 4:10 AM, Marcus G. Daniels mdani...@lanl.gov wrote: Hi, I'm wondering if anyone has looked at OpenCL as target for Data Parallel Haskell? Specifically, having Haskell generate CL kernels, i.e. SIMD vector type aware C language backend, as opposed to just a Haskell language binding. Thanks, Marcus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
Michael Snoyman schrieb: On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen ben.frank...@online.de mailto:ben.frank...@online.de wrote: Michael Snoyman wrote: On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? The error gets hidden instead of fixed? Cheers Ben You're right; bad programmers could do this. A good programmer will know to do one of two things when it gets an exception it does not know how to handle: It is certainly not the task of a programming language or a library to parent its users. Despite an interesting idea, it will not work, since programmers will simply switch to a different language or library if they feel pushed around. There is an important reason to not simply catch an error and proceed as if it were only an exception: The error might have corrupted some data and there is no general way to recover from that. Say, after detecting an error you might want to close a file that you were working on. But since you are coping with an error, something you did not foresee, you cannot tell whether the file was already closed again or never opened. So it is better to just abort the program. The next higher level, the shell calling your program or the browser calling your plugin, might have registered what have opened and allocated and can reliably free those resources. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
Hi, It probably helps to know some of the history, as it explains a lot of what you see today. Hoogle was written first (about 5 years ago now), before there was hackage (so it doesn't search hackage), and with an emphasis on type search (as that's cool). Hayoo came a lot later (about 2 years ago at most). Hoogle will be gaining the ability to do a full search of Hackage - I'm just waiting to get some bits sorted out first. There isn't really a technical obstacle, I've just not had the time to finish the implementation. Use whichever you choose, but if you use Hayoo for some reason other than Hoogle not searching all packages, I'd love to know. Thanks, Neil 2009/12/7 drostin77 ml.nwgr...@gmail.com: Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) I've just started learning Haskell (working my way through Real World Haskell and really liking it)! I have started to appreciate that there are a lot of Haskell libraries I will want to search and access quite regularly when I work on Haskell projects, so I had the following questions: 1. Hoogle and Hayoo: I'm a bit confused by the difference here. From initial impressions it seems that Hayoo is linked to Hackage, but Hoogle is not? And it seems that Hayoo is, well, Similar to Hoogle, but with less focus on type search. Should I check both of these when I want a library, or choose one and go with it...? Or is it indeed better to search Hayoo when I'm thinking of a named library and Hoogle when I think I know the type signature for just the function I need? 2. I much prefer a command line search interface to a browser, I see Hoogle offers such a tool, does Hayoo? P.S. If these questions are in the wrong place, or if they are already answered in detail somewhere that my Googling didn't find please feel free to paste a link and tell me to search better next time! -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26669924.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle Down
Hi Elliot, It is the right place, and Hoogle is now back up. Unfortunately the server it was run was out of disk space, which caused Hoogle to fail. Hopefully it won't happen again. Thanks, Neil 2009/11/29 Elliot Wolk elliot.w...@gmail.com: hello! im not sure that this is the correct mailing list for saying so, and also whether or not today's down-ness is just scheduled maintenance, but hoogle appears to be down again. sorry if this is known/redundant/not the right place! thanks, elliot ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: computing lists of pairs
Thanks again for your patience with me, your answers to this list (and the beginners list) are in general a real pleasure! Christian Daniel Fischer schrieb: Am Freitag 04 Dezember 2009 19:00:33 schrieb Christian Maeder: aP1 [] = [[]] aP1 (h:t) = do x - h xs - aP1 t return (x:xs) for every x in h, we calculate the combinations of t anew. Do we? Isn't aP1 t one closure that's being evaluated only once? That depends. Firstly, it depends on the optimisation level. -- module AllPossibilities where import Debug.Trace aP1 :: [[Int]] - [[Int]] aP1 [] = [[]] aP1 l@(h:t) = trace (aP1 ++ show l) [x:xs | x - h, xs - aP1 t] aP2 :: [[Int]] - [[Int]] aP2 [] = [[]] aP2 l@(h:t) = trace (aP2 ++ show l) [x:xs | xs - aP2 t, x - h] -- Compiled without optimisations (or interpreted): Prelude AllPossibilities aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] [[1,4,7],[1,4,8],[1,4,9]aP1 [[7,8,9]] ,[1,5,7],[1,5,8],[1,5,9]aP1 [[7,8,9]] ,[1,6,7],[1,6,8],[1,6,9]aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] ,[2,4,7],[2,4,8],[2,4,9]aP1 [[7,8,9]] ,[2,5,7],[2,5,8],[2,5,9]aP1 [[7,8,9]] ,[2,6,7],[2,6,8],[2,6,9]aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] ,[3,4,7],[3,4,8],[3,4,9]aP1 [[7,8,9]] ,[3,5,7],[3,5,8],[3,5,9]aP1 [[7,8,9]] ,[3,6,7],[3,6,8],[3,6,9]] Prelude AllPossibilities aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[4,5,6],[7,8,9]] aP2 [[7,8,9]] [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] it's evaluated multiple times. Compiled with optimisation (-O or -O2), Prelude AllPossibilities aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[1,2,3],[4,5,6],[7,8,9]] aP1 [[4,5,6],[7,8,9]] aP1 [[7,8,9]] [[1,4,7],[1,4,8],[1,4,9],[1,5,7],[1,5,8],[1,5,9],[1,6,7],[1,6,8],[1,6,9],[2,4,7],[2,4,8], [2,4,9],[2,5,7],[2,5,8],[2,5,9],[2,6,7],[2,6,8],[2,6,9],[3,4,7],[3,4,8],[3,4,9],[3,5,7], [3,5,8],[3,5,9],[3,6,7],[3,6,8],[3,6,9]] Prelude AllPossibilities aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[1,2,3],[4,5,6],[7,8,9]] aP2 [[4,5,6],[7,8,9]] aP2 [[7,8,9]] [[1,4,7],[2,4,7],[3,4,7],[1,5,7],[2,5,7],[3,5,7],[1,6,7],[2,6,7],[3,6,7],[1,4,8],[2,4,8], [3,4,8],[1,5,8],[2,5,8],[3,5,8],[1,6,8],[2,6,8],[3,6,8],[1,4,9],[2,4,9],[3,4,9],[1,5,9], [2,5,9],[3,5,9],[1,6,9],[2,6,9],[3,6,9]] it's only evaluated once. It's also evaluated only once (unoptimized) if given as follows, although I would not write it that way: aP1 :: [[Int]] - [[Int]] aP1 [] = [[]] aP1 l@(h:t) = trace (aP1 ++ show l) $ let r = aP1 t in [x:xs | x - h, xs - r] But if we think about what happens when we have n lists of lengths l1, ..., ln, there are l2*...*ln combinations of the tail. Each of these combinations is used l1 times, once for each element of the first list. However, between two uses of a particular combination, all the other (l2*...*ln-1) combinations are used once. If l2*...*ln is large, only a tiny fraction of the combinations of the tail fit in the memory at once, so they simply can't be reused and have to be recalculated each time (theoretically, a handful could be kept in memory for reuse). Right, memory consumption is still the problem (maybe unless everything is needed eventually). On the other hand, in aP2, each combination of the tail is of course also used l1 times, but these are in direct succession, and the combination has been bound to a name for the entire scope, it's practically guaranteed to be calculated only once and garbage collected once. Yes, I see that reusing and sharing one element of xs is far easier in aP2. By the way, if the order in which the combinations are generated matters: aP1 === map reverse . aP2 . reverse The order does not matter for me. But it is good to see (from a second perspective) that both variants basically produce the same combinations. aP2 [] = [[]] aP2 (h:t) = do xs - aP2 t x - h return (x:xs) now we first calculate the combinations of t, for each of those, we cons the elements of h to it in turn and never reuse it afterwards. Thanks for explaining. C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: binding to C libraries on Windoww
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Even then, there's no guarantee the right version will be found (google DLL Hell for examples of the chaos that ensues). This is particularly true for developers, who frequently have multiple versions of libraries installed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on configure. These packages will continue to require cygwin or mingw for the configure step. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
Neil Mitchell ndmitch...@gmail.com writes: but if you use Hayoo for some reason other than Hoogle not searching all packages, I'd love to know. Isn't it obvious? We all use Hayoo for the Web 2.0 interface! :p /me is just kidding -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SYB looping very, very mysteriously
On Sat, Dec 5, 2009 at 2:38 AM, Andrea Vezzosi sanzhi...@gmail.com wrote: On Fri, Dec 4, 2009 at 8:51 PM, Jeremy Shaw jer...@n-heptane.com wrote: I have stripped things down to the bare minimum, and test under GHC 6.10, GHC 6.12, Linux, and Mac OS X. Results are consistent. In the following code, 1. if you load the code into ghci and evaluate e it will hang, but (defaultValueD dict) :: Expression returns fine 2. if you change the gunfold instance for Proposition to, error gunfold it stops hanging -- even though this code is never called. 3. if you change, ( Data ctx [Expression], Sat (ctx Expression) = Data ctx Expression, to (Data ctx Expression, ) = ... it stops hanging. If someone could explain why each of these cases perform as they do, that would be awesome! Right now it is a big mystery to me.. e calls dict .. and there is only one instance of dict available, which should call error right away. I can't see how something could get in the way there... It's less of a mystery if you think about the actual dictionaries ghc uses to implement typeclasses. The instance for Data ctx [a] depends on Data ctx a, so by requiring Data ctx [Expression] in the Data ctx Expression instance you're indeed making a loop there, though typeclasses do allow this, and the implementation has to be lazy enough to permit it. Strange that with a direct Data ctx Expression = Data ctx Expression loop we don't get the same problem. The reason the implementation of Proposition's gunfold matters is probably that k gets passed the dictionary for Data DefaultD Expression at the site of its call and some optimization is making it stricter than necessary. Looks like we need a ghc dev here to fully unravel the mystery, in the meantime i'll try to reduce the test case even further. I have posted a ghc bug for this: http://hackage.haskell.org/trac/ghc/ticket/3731 and an syb-with-class bug, in case it is not a ghc bug (perhaps due to undecidable instances?):http://code.google.com/p/syb-with-class/issues/detail?id=3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Henning Thielemann escribió: A library function that reads a config file may declare to be able to throw the exception File not found, or it may introduce a new exception Could not read Config file with an extra field for the reason, why the file could not be read. This way you can construct a call stack that helps the user (and not the programmer). Then the message reported to the user might be: Program could not be started, because Config file could not be read because Config file does not exist in dir0, dir1, dir2 but the exception handler may also decide to use a default configuration instead or ask the user, how to proceed. Anyway, such a call stack for the user requires different information than a call stack for programmer for debugging. The point here being? My point has been As programming errors are something common lets at least make them easy to solve. If you make such a fancy stack the programmer is still clueless about where the unhandled exception was generated and can't solve it. There is also another important point here which is error recovery, it's not unusual to see on servers and other high availability programs a last barrier which would show info on the error and then restart/resume the server as if nothing has happened. Following your definition, now we have exceptions, not errors, as they are expected, though they made some harm to our transaction. Henning Thielemann escribió: The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception Well I got used to going back to the previous state without crashing when I got a precondition violation due to user input. Though I assume that was asking a bit too much of Haskell. Of course crashing the whole program as default behaviour is a better way to solve the problem. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: PortAudio Windows Tutorial and Binaries
Very cool. On Sun, Dec 6, 2009 at 7:29 PM, M Xyz functionallyharmoni...@yahoo.comwrote: I got a lot of great help this weekend from Haskell-Cafe, thanks. Now that I have portaudio up and running I put up a tutorial and a 103 kb download of all the windows binaries and files. I hope this helps people exploring digital audio with Haskell. http://www.subreddits.org/misc/haskell/portaudio.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is it possible: Haskell platform - portable edition
Hello, Has anyone considered the possibility of making a *Portable* Haskell Platform distribution (portable meaning on a USB stick) for Windows? This worked form me: I installed GHC on one machine, copied it to a USB stick and created a batch to set the environment path and open a command prompt. This gives me the freedom to use Haskell wherever I am! The only downside is that I have to edit packages.conf by hand everytime I install a package. I would like to improve this, by making it more automatic. Do you haskellers think it is possible? Regards, Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A bug of groupBy implement
Hi there: My friend asked me a question, and i suppose he has found a bug of `groupBy'. Here is the code piece: List.groupBy (\a b - Foreign.unsafePerformIO (Text.Printf.printf \t%d = %d ?: %s\n a b (show (a=b)) return (a=b))) [7,3,5,9,6,8,3,5,4] I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 = 3 ?: False 3 = 5 ?: True 3 = 9 ?: True 3 = 6 ?: True 3 = 8 ?: True 3 = 3 ?: True 3 = 5 ?: True 3 = 4 ?: True [[7],[3,5,9,6,8,3,5,4]] Regards -- L.Guo 2009-12-08 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A bug of groupBy implement
Could it not be a bug in a) printf b) unsafePerformIO c) d) return e) = f) show g) GHC or GHCi? All of the above? Best wishes Stephen 2009/12/7 L.Guo leaveye@gmail.com: Hi there: My friend asked me a question, and i suppose he has found a bug of `groupBy'. Here is the code piece: List.groupBy (\a b - Foreign.unsafePerformIO (Text.Printf.printf \t%d = %d ?: %s\n a b (show (a=b)) return (a=b))) [7,3,5,9,6,8,3,5,4] I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 = 3 ?: False 3 = 5 ?: True 3 = 9 ?: True 3 = 6 ?: True 3 = 8 ?: True 3 = 3 ?: True 3 = 5 ?: True 3 = 4 ?: True [[7],[3,5,9,6,8,3,5,4]] Regards -- L.Guo 2009-12-08 ___ 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[2]: [Haskell-cafe] A bug of groupBy implement
Hello Stephen, Monday, December 7, 2009, 8:11:01 PM, you wrote: it's just what goupBy compares with the first element of group rather than comparing two adjancent elements. look at the trace it's not a bug, but misunderstanding of specification :) Could it not be a bug in a) printf b) unsafePerformIO c) d) return e) = f) show g) GHC or GHCi? All of the above? Best wishes Stephen 2009/12/7 L.Guo leaveye@gmail.com: Hi there: My friend asked me a question, and i suppose he has found a bug of `groupBy'. Here is the code piece: List.groupBy (\a b - Foreign.unsafePerformIO (Text.Printf.printf \t%d = %d ?: %s\n a b (show (a=b)) return (a=b))) [7,3,5,9,6,8,3,5,4] I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 = 3 ?: False 3 = 5 ?: True 3 = 9 ?: True 3 = 6 ?: True 3 = 8 ?: True 3 = 3 ?: True 3 = 5 ?: True 3 = 4 ?: True [[7],[3,5,9,6,8,3,5,4]] Regards -- L.Guo 2009-12-08 ___ 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 -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A bug of groupBy implement
On Tue, Dec 08, 2009 at 12:45:59AM +0800, L.Guo wrote: Hi there: My friend asked me a question, and i suppose he has found a bug of `groupBy'. Here is the code piece: List.groupBy (\a b - Foreign.unsafePerformIO (Text.Printf.printf \t%d = %d ?: %s\n a b (show (a=b)) return (a=b))) [7,3,5,9,6,8,3,5,4] I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 = 3 ?: False 3 = 5 ?: True 3 = 9 ?: True 3 = 6 ?: True 3 = 8 ?: True 3 = 3 ?: True 3 = 5 ?: True 3 = 4 ?: True [[7],[3,5,9,6,8,3,5,4]] This looks like the right result to me. What makes you think it is wrong? What result do you expect? -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Haskell Web News: December 2009 Edition
The Haskell Web News is a monthly summary of the hottest news about the Haskell programming language, as found in our online communities. If you want to catch up with what’s been happening in Haskell, this might be the journal for you. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ What’s been happening with the Haskell programming language for the past month, as voted by readers of The Haskell Reddit. This is the first edition of the Web News, so feedback on the content, schedule and goals is welcome. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A bug of groupBy implement
Hi, I have tested it in GHC 6.10.4 (Win XP) and GHC 6.8.3 (Linux), both give the wrong result (categaried): 7 = 3 ?: False 3 = 5 ?: True 3 = 9 ?: True 3 = 6 ?: True 3 = 8 ?: True 3 = 3 ?: True 3 = 5 ?: True 3 = 4 ?: True [[7],[3,5,9,6,8,3,5,4]] What exactly is wrong with this result? All of the above comparisons seem to get the right result, and they say 7 is not in the same categorie as 3, but all other numbers are in the same category as 3. So the returned list looks ok too. Perhaps you had expected another output list (please tell us what you think you've found a bug!)? In fact, it seems that any output list would have been correct, since you're using a comparison function that is not symmetrical. In other words, you're say 7 should be in the same category as 3, but 3 should not be in the same category as 7. Since nothing is guaranteed about the order in which groupBy compares elements, any grouping could be achieved by letting groupBy choose the right ordering. So, it seems your comparison function is wrong since it does not satisfy the (unwritten) requirement of symmetry? Gr. Matthijs signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell Web News: December 2009 Edition
2009/12/7 Don Stewart d...@galois.com: The Haskell Web News is a monthly summary of the hottest news about the Haskell programming language, as found in our online communities. If you want to catch up with what’s been happening in Haskell, this might be the journal for you. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ What’s been happening with the Haskell programming language for the past month, as voted by readers of The Haskell Reddit. This is the first edition of the Web News, so feedback on the content, schedule and goals is welcome. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I think the correct URL should be: http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ Yours didn't work for me. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell Web News: December 2009 Edition
On Mon, Dec 7, 2009 at 11:25 AM, Deniz Dogan deniz.a.m.do...@gmail.com wrote: 2009/12/7 Don Stewart d...@galois.com: The Haskell Web News is a monthly summary of the hottest news about the Haskell programming language, as found in our online communities. If you want to catch up with what’s been happening in Haskell, this might be the journal for you. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ I think the correct URL should be: http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ Actually, I think it's: http://haskellwebnews.wordpress.com/2009/12/06/whats-new-in-haskell-december-2009/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell Web News: December 2009 Edition
Deniz: I think the correct URL should be: Oops, well spotted. The original link will work now. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell Web News: December 2009 Edition
2009/12/7 Tom Tobin korp...@korpios.com: On Mon, Dec 7, 2009 at 11:25 AM, Deniz Dogan deniz.a.m.do...@gmail.com wrote: 2009/12/7 Don Stewart d...@galois.com: The Haskell Web News is a monthly summary of the hottest news about the Haskell programming language, as found in our online communities. If you want to catch up with what’s been happening in Haskell, this might be the journal for you. http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ I think the correct URL should be: http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ Actually, I think it's: http://haskellwebnews.wordpress.com/2009/12/06/whats-new-in-haskell-december-2009/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Of course, that's what I meant. :) -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell Web News: December 2009 Edition
Hello Don, Monday, December 7, 2009, 8:16:25 PM, you wrote: http://haskellwebnews.wordpress.com/2009/12/05/whats-new-in-haskell-december-2009/ can we make download counts for individual packages available? my own program (http://freearc.org) has about 10k downloads/month so i doubt what place it may have among all haskell applications :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A bug of groupBy implement
Hi L.Guo Brent has replied with the right answer. The definition of groupBy is below - the span in the where clause only compares with the first element of the current sub-list: -- | The 'groupBy' function is the non-overloaded version of 'group'. groupBy :: (a - a - Bool) - [a] - [[a]] groupBy _ [] = [] groupBy eq (x:xs) = (x:ys) : groupBy eq zs where (ys,zs) = span (eq x) xs -- list1 = [7,3,5,9,6,8,3,5,4::Int] Here are two more runs on your input with a wee bit less clutter. In both cases there are 'spans' where the numbers increase and decrease - this is because the operation is comparing the rest of the input against the first element in the 'span' not consecutive elements. *GroupBy Data.List groupBy () list1 [[7],[3,5,9,6,8],[3,5,4]] *GroupBy Data.List groupBy (=) list1 [[7],[3,5,9,6,8,3,5,4]] Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: binding to C libraries on Windoww
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. If Windows lacks a sane environment, why not to provide one? I don't know how much of it mingw already provides. If it doesn't, that would be a nice Haskell project :) It could be called Windows SaneEnvironment, and include a few basic policies for packages and a package manager. When I needed Windows myself I would certainly help maintaining. It would not be hard to find others who still will. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Mon, Dec 7, 2009 at 2:13 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: Michael Snoyman schrieb: On Mon, Dec 7, 2009 at 5:30 AM, Ben Franksen ben.frank...@online.de mailto:ben.frank...@online.de wrote: Michael Snoyman wrote: On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? The error gets hidden instead of fixed? Cheers Ben You're right; bad programmers could do this. A good programmer will know to do one of two things when it gets an exception it does not know how to handle: It is certainly not the task of a programming language or a library to parent its users. Despite an interesting idea, it will not work, since programmers will simply switch to a different language or library if they feel pushed around. How did you get from what I said that I have any desire to parent users of a language? I think my sentiment is clear: a bad programmer will do bad things with any tool. I don't care about how a bad programmer might screw things up. In fact, I think your ideas are much more likely to give the feeling of being pushed around. The only opinion I've stated so far is that it's ridiculous to constantly demand that people follow your definition of error vs exception, since the line is incredibly blurry and it buys you very little. However, my opinion on what libraries should do is simple: Provide a simple, uniform interface for receiving both errors and exceptions, and let the library user decide what to do with them. If they are unhandable, then don't handle them; if a user *does* handle something which can't be dealt with, they fall into the over-defensive bad programmer category and I don't care. Otherwise, it gives people the flexibility that they need in all cases. I think under no circumstances* should a library simply terminate a runtime because it decides to. This is one of the great things of being able to catch all errors. * Of course, there are no absolutes. Ever. Not a single one. There is an important reason to not simply catch an error and proceed as if it were only an exception: The error might have corrupted some data and there is no general way to recover from that. Say, after detecting an error you might want to close a file that you were working on. But since you are coping with an error, something you did not foresee, you cannot tell whether the file was already closed again or never opened. So it is better to just abort the program. The next higher level, the shell calling your program or the browser calling your plugin, might have registered what have opened and allocated and can reliably free those resources. And what if you're calling a library in the same runtime? I think you are conflating the idea of treating errors as exceptions, which I think is a good one, and not letting there be any distinction between errors and exceptions, which is a bad one. The fact that I can use Control.Exception.catch to catch either errors or exceptions, but I can differentiate based on the data type, is IMO a great solution to this issue. I also believe that the failure package is a better** solution to the problem, because it makes it exceedingly clear which error/exception might have occurred. ** Of course, failure cannot handle a lot of what IO exceptions can, so it's a silly comparison in general. However, for the purpose of good error/exception handling, I think it's a better solution. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
On Mon, 7 Dec 2009, Michael Snoyman wrote: The only opinion I've stated so far is that it's ridiculous to constantly demand that people follow your definition of error vs exception, since the line is incredibly blurry and it buys you very little. If you have an example that is not contained in my article on the Haskell Wiki, where you think the error vs. exception distinction is not appropriate, please let me know and will think about it. http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
On Mon, Dec 7, 2009 at 9:07 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 7 Dec 2009, Michael Snoyman wrote: The only opinion I've stated so far is that it's ridiculous to constantly demand that people follow your definition of error vs exception, since the line is incredibly blurry and it buys you very little. If you have an example that is not contained in my article on the Haskell Wiki, where you think the error vs. exception distinction is not appropriate, please let me know and will think about it. http://www.haskell.org/haskellwiki/Error_vs._Exception I think it's a silly, unnecessary distinction. Sure, when you're teaching beginning programmers how to deal with out-of-bounds versus file not found, you can use the terminology. But as far as insisting that library authors have their programs die on an error, it's pointless. Having errors thrown as their own type of exception (like AssertionFailed, for example) is a much more resilient option, and for decent programmers who understand they shouldn't just catch every exception and return a default value, there is no downside. I don't care to make systems less resilient to deal with the sub-par programmer. I turn it around: give me an example where it's better for the runtime to exit than for some type of exception to be thrown, and *I'll* think about it ;). Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
I turn it around: give me an example where it's better for the runtime to exit than for some type of exception to be thrown, and *I'll* think about it ;). If you would have read my article, you had one ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
Somehow I missed this thread. I want to say that I have implemented a general
way to add the information of an exception to the end of an arbitrary data
structure.
http://hackage.haskell.org/packages/archive/explicit-exception/0.1.4/doc/html/Control-Monad-Exception-Asynchronous.html
Duncan already mentioned it:
data Exceptional e a = Exceptional {
exception :: Maybe e
result:: a
}
However it's pretty clear from the structure of this type that it cannot
cope with lazy error handling in sequences. If you try it you'll find
you cannot do it without space leaks.
Actually you spotted the space leak - but how is it pretty clear, that it
has the space leak? I wondered why 'unzip' does not have the space leak,
although when I sequence a lot of Exceptional values using mconcat, I'm
doing something pretty similar.
I also agree with you, that the possibility to access the result directly,
and thus easily ignore the exception is bad. I thought it could be
improved by removing the field accessors and instead provide the function:
switch :: (Maybe e - c) - (a - c) - Exceptional e a - c
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
@Apfelmus: For practical purposes I think Train should have swapped type parameters in order to make Functor act on the type of the list elements. data Train b a = Wagon a (Train b a) | Loco b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
On Mon, 7 Dec 2009, Michael Snoyman wrote: I actually *did* read your article, and don't know what you are referring to. If this is true, sorry, I didn't had the impression. I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
Excerpts from Henning Thielemann's message of Mon Dec 07 20:36:27 +0100 2009: @Apfelmus: For practical purposes I think Train should have swapped type parameters in order to make Functor act on the type of the list elements. data Train b a = Wagon a (Train b a) | Loco b The functor on the Loco/Caboose makes sense too and swapping the arguments is less natural to read. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 7 Dec 2009, Michael Snoyman wrote: I actually *did* read your article, and don't know what you are referring to. If this is true, sorry, I didn't had the impression. I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. Firstly: I'm really referring exclusively to non-FFI Haskell programs, to which most of the issues you mention don't really apply. Nonetheless, I think that for a language with exceptions, it still makes sense to use the exceptions in these cases. In all these cases, I think the correct thing is to have a specific exception type that is thrown that signals that it is such an unrecoverable error. This allows the programmer to do *whatever* they want. Perhaps they want to save some other data to a file before exiting? Perhaps they want to spawn a process to send in a bug report? Who knows. It doesn't matter. The point is, the user *might* want to do something, and exceptions let them do it if they wish, or they can completely ignore that specific exception type and let the program crash anyway. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
2009/12/07 klondike klondikehaskellc...@xiscosoft.es: Well I got used to going back to the previous state without crashing when I got a precondition violation due to user input. Though I assume that was asking a bit too much of Haskell. It's too much to ask of partial functions. If you want to state your preconditions and rollback in an appropriate monad, that's of a horse of a different color. Of course crashing the whole program as default behaviour is a better way to solve the problem. If you're not working in a side-effecting or sequential subset of the language, you can't really expect to have a consistent notion of the state before the crash. It's a declarative, lazy language, after all. Consider, also, that a crash is just one of the problems you get with bad input; another one is infinite loops. As Henning Thielemann points out in his wiki article, you can't expect to catch those as they don't throw exceptions or cause any errors! You need to validate the input or use a timer in that case. Relying on the program to crash in a timely manner if something is wrong with the input is not a strategy that is going to go the distance. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Zumkeller numbers
Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html My C/C# solutions looks clumsy (but is fast). I think this can be done much more elegant in Haskell with lazy evaluation. Not related to Haskell, but do you think semi-Zumkeller numbers are semi-perfect numbers? Maybe some Haskell code for testing it for some numbers? -- Frank Buss, f...@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: binding to C libraries on Windoww
Jeffrey Scofield wrote: I think the real cultural difference is that you aren't a user, you're a prospective Haskell developer, as others have said. Developers pretty much have to install tools (like compilers and preprocessors) and have to work with source code. And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs. Traditionally, Unix *comes with* thousands of tools that are useful to developers. Windows traditionally came with none, at least none that I was ever able to find. True. By default, Windows assumes you are a clueless user, not an expert developer. Since many of the traditional Unix tools are available free, it makes sense that somebody would want to port them to Windows *for doing development*. It's not so much a Unix emulation as a solution to the lack of native Windows tools. Of course this makes sense especially to somebody who has gotten used to the Unix tools (such as myself). I would never try to *develop* seriously under Windows using just what comes preinstalled. You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...) Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.) The thing is, if you're a C programmer on Windows, and you want to write (say) a program that talks to an Oracle database, typically what you'd do is install Visual Studio, download the Net8 client DLLs and header files, compile your application against the Net8 client header files, link everything, and when your program runs, it dynamically loads the Net8 DLLs and does its work. But it seems that if I want to talk to Oracle from Haskell, I'm expected to find the *source code* to the Net8 client and *compile it from source*. This is highly unusual for Windows. (I wouldn't be surprised if Oracle haven't even released the source code for their Net8 libraries...) It just isn't the way Windows usually works. Even without VS, if I'm working in C, all I really need is a compiler and a linker, and I can build an executable program that talks to Oracle. But with Haskell, it seems I need to be able to actually build the Net8 client from source - which, depending on how those sources are written, is likely to require an entire build system (Automake, a VS project, whatever). It's a much bigger undertaking than just compiling the few source file I personally wrote and linking a few bits together. This is not to say that on a given day it isn't frustrating when you can't get something to compile, especially if it's just a tool you need to compile something else. Oh, hey, I understand why things are like this. You make something work properly on Linux, and with not that much effort you can make it also work for BSD, Mac OS, Solaris, HP UX... even certain embedded devices can potentially run it. You want to make something work on Windows? You have to do everything totally differently. (No wonder people thought that things like Cygwin and MinGW were a good idea.) One of the things that has impressed me about GHC is that it takes Windows seriously. The compiler and interpretter both work flawlessly on Windows. They don't try to teraform Windows into just another Unix, they actually try to do things The Windows Way. I like that. And it's not like all of Hackage is useless to me; anything that's 100% Haskell compiles and installs first time, almost every time. It's just frastrating that all the cool multimedia stuff I'd like to be doing requires access to C, and that's still currently very difficult. I understand not many Haskell people use Windows, so it's not so easy for people to test, and not so many people have a detailed knowledge of Windows. And with this latest discussion, I'm beginning to understand why binding to C is so hard. But, yeah, it *is* still frustrating. ;-) And, unfortunately, I lack the knowledge or skill to be able to improve the situation... But this is why developers are so wealthy, they have the fortitude to work through these problems. (Ha ha.) Heh, good one. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: binding to C libraries on Windoww
John Lato wrote: To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. Agreed. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Also agreed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry), or possibly the *developer* package comes as a simple Zip file that you just unzip to wherever you fancy. Just tell the user the URL to grab the Zip file from, unzip it and tell Cabal where the root is now. Shouldn't be too hard. (Famous last words...) The problem, of course, is that, especially if the file layout differs significantly in the Windows version of the library, this is going to absolutely _require_ somebody with a real Windows box and familiarity with Windows to work on the Cabal packaging. (In extreme cases you might even end up needing a completely seperate, Windows-only Cabal file.) Presumably nobody will ever have the time or inclination to construct this. On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on configure. These packages will continue to require cygwin or mingw for the configure step. Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it. I gather it's supposed to be Cabal's job to figure this stuff out in Haskell land? One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. This seems to be kind of the catch-22. Nobody uses Windows, so there isn't much support for Windows, so we don't attract many Windows users... QED. :-} C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. In other words, Windows needs to become just like Unix. Not going to happen. ;-) Argue about whether this is good or bad amoungst yourselves. But it's not happening. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh* ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
Here's a completely naive implementation, it's slow as cold molasses going uphill during a blizzard, but it doesn't seem to be wrong. I let it run in the interpreter for the last 3 minutes or so and it's reproduced the given list up to 126 (and hasn't crapped out yet). I imagine there's probably a less naive algorithm that could be done, but I rather like the straightforwardness of this one... /Joe module Main where import Control.Monad(filterM) import Data.List(sort) divisors :: Int - [Int] divisors n = [d | d - [1..n], n `mod` d == 0] powerset = filterM (const [True, False]) () :: Eq a = [a] - [a] - [(a,a)] x y = [(x', y') | x' - x, y' - y, x' /= y'] (/\) :: Eq a = [a] - [a] - Bool x /\ y = null $ filter (`elem` x) y prod m n = filter (uncurry (/\)) (m n) eqSum :: ([Int], [Int]) - Bool eqSum (m, n) = sum m == sum n containsAllDivisors i l = filter (\x - (sort . uncurry (++) $ x) == divisors i) l zumkeller :: Int - [([Int], [Int])] zumkeller n = containsAllDivisors n . filter eqSum . (\x - prod x x) $ allParts where divs = divisors n allParts = powerset divs zumkellerP :: Int - Bool zumkellerP = not . null . zumkeller --- On Dec 7, 2009, at 4:33 PM, Frank Buss wrote: Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html My C/C# solutions looks clumsy (but is fast). I think this can be done much more elegant in Haskell with lazy evaluation. Not related to Haskell, but do you think semi-Zumkeller numbers are semi-perfect numbers? Maybe some Haskell code for testing it for some numbers? -- Frank Buss, f...@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: binding to C libraries on Windoww
Andrew Coppin wrote: Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry) Is that done automatically or does the installer have to explicity set it? What does it look like? The reason I ask is that I release a binary windows installer for libsndfile. The binaries are generated using a Linux to Windows cross-compiler and for the win32 version I run the testsuite under Wine (windows API emulator). I then run INNO Setup under wine to generate the installer executable. On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on configure. These packages will continue to require cygwin or mingw for the configure step. Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it. There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard. There is stuff in that standard that makes my life easier so I use it in libsndfile. Its also why I much prefer to cross compiler from Linux to Windows with a GNU compiler that supports the vast majority of the 1999 ISO C Standard. I would be possible to make libsndfile compile with Microsofts compiler but it would add a whole bunch of #ifdefs all over the place making the code base fragile and in the long term less maintainable and reliable. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though. Ignoring bugs and features that are common across all platforms in libsndfile I have spent at least an order of magnitude more time and effort getting things working with windows that I have with all of the Unixes (including OSX) summed together. This for a platform I don't use. Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh* If those libraries use parts of the C99 standard then yes. Microsoft has had 10 years to make their compilers compliant. Ask them why they haven't. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
On Mon, 7 Dec 2009, Frank Buss wrote: Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html My C/C# solutions looks clumsy (but is fast). I think this can be done much more elegant in Haskell with lazy evaluation. http://darcs.haskell.org/htam/src/Example/Zumkeller.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is anyone reading Pattern Calculus by Barry Jay?
Thanks Bernie, I've applied for membership in the forum. I'm grateful that technology can connect me with so distant but interesting a group! Duane On Dec 7, 2009, at 12:41 AM, Bernie Pope florbit...@gmail.com wrote: 2009/12/7 Duane Johnson duane.john...@gmail.com: I just bought a copy of Pattern Calculus [1] by Barry Jay and I would like to discuss the lambda- and pattern-calculus with anyone who is interested. Is there anyone else here who is reading the book and would like to discuss here (if it is appropriate) or take the discussion elsewhere? My knowledge of types has come primarily through reading this Haskell Cafe list, so I am by no means an expert. Just a tinkerer :) Regards, Duane Johnson [1] http://lambda-the-ultimate.org/node/3695 Hi Duane, The Melbourne FPU (functional programming union) is interested in topics like this, and some of us have a copy, or are about to get a copy of the book. http://groups.google.com.au/group/fpunion There's already a short thread on the topic - please feel free to sign up to the group. We welcome stimulating discussion. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
When I was working at Quintus, I came up with a classification which I can simplify something like this: operating system fault Something bad happened (like a remote node going down) that was entirely out of your control. There is nothing you can do to your program to prevent this. Example: power failure. It's still your problem to clean up on your way out. resource faults your program tried to do something possibly meaningful but the system ran out of some kind of resource (cpu limit, memory limit, disc quota, c) You might respond to this by increasing the limit and trying again. representation faults your program tried to do something meaningful but the system was unable to represent the result (integer overflow, upper case of ÿ in a Latin 1 system, floating point overflow on a non-IEEE system, c) Your program isn't *wrong* but you will still have to change it. existence errors Your program tried to do something with a (typically external) resource that doesn't exist (missing file) Your program could be wrong but probably isn't. You will have to create the resource or provide a different name. permission errors Your program tried to do something to a (typically external but not always) resource that you do not have permission to do (typically writing to a read-only file) You may have named the wrong resource. If not, you may have to get the permissions for the resource changed, or ask someone else to run the program. domain errors A precondition on the input arguments of an operation was not satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). Your program is definitely wrong. postcondition errors Your program invoked some operation and the precondition for the operation was satisfied, but when it completed, the postcondition was not. The operation you invoked is broken. If it's yours, you will have to fix it. If the precondition was not strong enough, it may be your program at fault. Otherwise, until you can get a fix from someone, you will have to program around it. I didn't find a simple error/exception distinction helpful, and still don't. Take the case of trying to write to /dev/nul. This is a permission error. If the program is responsible for the name being what it is, it's a mistake in the program. If the user typed the name in, it's the user's mistake. You really can't tell without tracing each value to its origin. I dare ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenCL target for DPH?
Marcus Daniels wrote, I'm wondering if anyone has looked at OpenCL as target for Data Parallel Haskell? Specifically, having Haskell generate CL kernels, i.e. SIMD vector type aware C language backend, as opposed to just a Haskell language binding. The short answer is that there is currently no plan to directly target OpenCL from DPH. (That is the DPH team doesn't have any such plans, but if anybody else wants to give it a shot, the latest, bleeding edge DPH code is always available in the GHC HEAD repository.) The long answer is that we are currently working on two separate data-parallel extensions for Haskell. Data Parallel Haskell http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell ~ Here the focus is *expressiveness*. In particular, we support arbitrarily deep, dynamic nesting of dataparallel computations with full support of higher-order functions (ie, parallel arrays of functions are fine). However, to keep the work manageable, we only target multicore CPUs for the moment (using the multi-threading support in GHC's RTS). Data.Array.Accelerate http://www.cse.unsw.edu.au/~chak/project/accelerate/ ~ Here the focus is on targeting *exotic, high-performance hardware*. We are currently working on a CUDA backend targeting CUDA-capable NVIDIA GPUs, but it shouldn't be too hard to re-target that to OpenCL. Support for the Cell BE and FPGAs appears feasible, too (but we lack local expertise and hardware to write such backends ourselves). However, to keep the work manageable, we only consider regular, multi-dimensional array codes encoded in an embedded DSL where functions are not first-class (ie, we use Haskell's first-class functions to implement the EDSL, but the embedded language is first-order). Longer term future ~~ At some point, we would of course like to bring the above two projects together, but at the moment, each is already rather challenging just by itself. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
Am Montag 07 Dezember 2009 22:33:32 schrieb Frank Buss: Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html My C/C# solutions looks clumsy (but is fast). I think this can be done much more elegant in Haskell with lazy evaluation. A fairly naive but not too slow version: - module Main (main) where import Data.List (sort) import Control.Monad (liftM2) import System.Environment (getArgs) main = do args - getArgs let bd = case args of (a:_) - read a _ - 1000 mapM_ print $ filter isZumkeller [2 .. bd] trialDivPrime :: [Int] - Int - Bool trialDivPrime (p:ps) n = (p*p n) || (n `mod` p /= 0) trialDivPrime ps n oprs = 5:7:filter (trialDivPrime oprs) (scanl (+) 11 $ cycle [2,4]) primes :: [Int] primes = 2:3:oprs factors :: Int - [(Int,Int)] factors n | n 0 = factors (-n) | n == 0= [(0,1)] | otherwise = go n primes where go 1 _ = [] go m (p:ps) | p*p m = [(m,1)] | otherwise = case m `quotRem` p of (q,0) - case countFactors q p of (m',k) - (p,k+1):go m' ps _ - go m ps countFactors :: Int - Int - (Int,Int) countFactors n p = go n 0 where go m k = case m `quotRem` p of (q,0) - go q (k+1) _ - (m,k) divisors :: Int - [Int] divisors n = sort $ foldr (liftM2 (*)) [1] ppds where ppds = map (\(p,k) - take (k+1) $ iterate (*p) 1) $ factors n partition :: Int - [Int] - [[Int]] partition 0 _ = [[]] partition n [] = [] partition n (p:ps) | n p = partition n ps | otherwise = [p:parts | parts - partition (n-p) ps] ++ partition n ps isZumkeller :: Int - Bool isZumkeller n | sigma 2*n = False | odd sigma = False | otherwise = not . null $ partition target candidates where divs = divisors n sigma = sum divs target = (sigma-n) `quot` 2 candidates = reverse $ takeWhile (= target) divs Of course, with sieving, you'd be much faster. Not related to Haskell, but do you think semi-Zumkeller numbers are semi-perfect numbers? The site you linked to says so. I've not investigated. Maybe some Haskell code for testing it for some numbers? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SmallCheck design question
referring to the Serial instances in http://hackage.haskell.org/package/smallcheck : the idea is that series d gives all objects of depth = d. depth of a term from an algebraic data type is the standard depth concept for trees (maximum nesting of constructors = longest path from root to node) 1. why are the tuple constructors treated differently? I'd expect depth (x,y) = succ $ max (depth x) (depth y) but the succ is missing. 2. why depth and not size (= total number of constructors)? it seems that the number of objects (trees) of given depth rises much more drastically than number of trees of given size. just wondering - J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Hackage category: Error Handling
Michael Snoyman wrote: On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 7 Dec 2009, Michael Snoyman wrote: I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. Firstly: I'm really referring exclusively to non-FFI Haskell programs, to which most of the issues you mention don't really apply. Nonetheless, I think that for a language with exceptions, it still makes sense to use the exceptions in these cases. In all these cases, I think the correct thing is to have a specific exception type that is thrown that signals that it is such an unrecoverable error. This allows the programmer to do *whatever* they want. Perhaps they want to save some other data to a file before exiting? Perhaps they want to spawn a process to send in a bug report? Who knows. It doesn't matter. The point is, the user *might* want to do something, and exceptions let them do it if they wish, or they can completely ignore that specific exception type and let the program crash anyway. Michael, Henning There are two meanings to the word 'exception' in this context; both of you tend to conflate these different meanings. One meaning is about a *mechanism* for non-local control flow; the other is about certain classes of un-desired program conditions. Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me. There are certainly good use cases, you have presented a few. However, that does not mean it is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and other kinds of expected exceptional conditions in general, as you claimed in a previous message. I agree with Henning insofar as I think it is important to make the *conceptual* distinction -- regardless of whether we use the same mechanism to signal (and, perhaps, after serious consideration, handle) them. So, maybe it would help if we could agree to use different terms for those two meanings of the word 'exception'. I think 'exception' is too strongly associated with the non-local control flow mechanism to introduce a new word for it. Henning, what about calling an undesired but expected condition a 'failure' instead of an exception, so we could reserve this word for the language mechanism? Calling something a 'failure' in this sense (i.e. in contrast to 'error') would always include some judgement, as it needs to take the different program levels into account. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, 8 Dec 2009, Richard O'Keefe wrote: When I was working at Quintus, I came up with a classification which I can simplify something like this: It's certainly possible to classify errors and exceptions in other (also more fine grained) ways ... operating system fault Something bad happened (like a remote node going down) that was entirely out of your control. There is nothing you can do to your program to prevent this. Example: power failure. It's still your problem to clean up on your way out. This is an exception. Of course, if the machine your program runs on goes out of power, then neither exception handling nor debugging will help. resource faults your program tried to do something possibly meaningful but the system ran out of some kind of resource (cpu limit, memory limit, disc quota, c) You might respond to this by increasing the limit and trying again. An exception. representation faults your program tried to do something meaningful but the system was unable to represent the result (integer overflow, upper case of ÿ in a Latin 1 system, floating point overflow on a non-IEEE system, c) Your program isn't *wrong* but you will still have to change it. It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error. existence errors Your program tried to do something with a (typically external) resource that doesn't exist (missing file) Your program could be wrong but probably isn't. You will have to create the resource or provide a different name. Exception permission errors Your program tried to do something to a (typically external but not always) resource that you do not have permission to do (typically writing to a read-only file) You may have named the wrong resource. If not, you may have to get the permissions for the resource changed, or ask someone else to run the program. Exception domain errors A precondition on the input arguments of an operation was not satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). Your program is definitely wrong. X/0, sqrt(-1), head [] are errors Malformed constant file name in your program is an error but it will raise an exception. The fix is to correct the filename, but you will still need the exception handling, since also the file with the correct name might not exist. postcondition errors Your program invoked some operation and the precondition for the operation was satisfied, but when it completed, the postcondition was not. The operation you invoked is broken. If it's yours, you will have to fix it. If the precondition was not strong enough, it may be your program at fault. Otherwise, until you can get a fix from someone, you will have to program around it. This is an error. Take the case of trying to write to /dev/nul. This is a permission error. If the program is responsible for the name being what it is, it's a mistake in the program. If the user typed the name in, it's the user's mistake. You really can't tell without tracing each value to its origin. Sure, the distinction exception/error depends on the source of the data that causes problems.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
On Dec 8, 2009, at 10:33 AM, Frank Buss wrote: Anyone interested in writing some lines of Haskell code for generating the Zumkeller numbers? http://www.luschny.de/math/seq/ZumkellerNumbers.html These lines of Haskell code find the Zumkeller numbers up to 5000 in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took 1.1 seconds. Note that this just finds whether a suitable partition exists; it does not report the partition. factors :: Int - [Int] factors n = [m | m - [1..n], mod n m == 0] can_part :: [Int] - Int - Bool can_part _ 0 = True can_part xs t = loop xs [] where loop [] _ = False loop (x:xs) ys = x = t can_part (xs++ys) (t-x) || loop xs ys is_Zumkeller :: Int - Bool is_Zumkeller n = let facs = factors n fsum = sum facs in mod fsum 2 == 0 can_part facs (div fsum 2) main = print (filter is_Zumkeller [1..5000]) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: binding to C libraries on Windoww
On Mon, Dec 7, 2009 at 4:37 PM, Andrew Coppin andrewcop...@btinternet.comwrote: And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs. snip You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...) Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.) It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio. I think that it makes sense that open source software developers targeting multiple platforms would want to pick a tool suite that works across all those platforms, and the GNU tools fit that description. Cygwin truly is a Unix emulation, but MinGW/MSYS is just a packaging of useful open source (GNU) tools for Windows (including a shell). Many programs that work well as native Windows apps, such as the GIMP, are built with them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Zumkeller numbers
From: daniel.is.fisc...@web.de [mailto:daniel.is.fisc...@web.de] Not related to Haskell, but do you think semi-Zumkeller numbers are semi-perfect numbers? The site you linked to says so. I've not investigated. Peter Luschny posted the link in a discussion in a German newsgroup: http://tinyurl.com/y9kfdpf Currently it is a conjecture and needs a proof before posting it to Sloane's integer sequences archive. -- Frank Buss, f...@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Zumkeller numbers
From: Richard O'Keefe [mailto:o...@cs.otago.ac.nz] These lines of Haskell code find the Zumkeller numbers up to 5000 in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took 1.1 seconds. Note that this just finds whether a suitable partition exists; it does not report the partition. factors :: Int - [Int] factors n = [m | m - [1..n], mod n m == 0] can_part :: [Int] - Int - Bool can_part _ 0 = True can_part xs t = loop xs [] where loop [] _ = False loop (x:xs) ys = x = t can_part (xs++ys) (t-x) || loop xs ys is_Zumkeller :: Int - Bool is_Zumkeller n = let facs = factors n fsum = sum facs in mod fsum 2 == 0 can_part facs (div fsum 2) main = print (filter is_Zumkeller [1..5000]) Thanks, I like this solution! Pure functional, easy to understand, no monads and fast :-) -- Frank Buss, f...@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: binding to C libraries on Windoww
On Dec 8, 2009, at 11:00 AM, Andrew Coppin wrote: In other words, Windows needs to become just like Unix. Not going to happen. I have the use of a dual-boot MacOS/Vista laptop. Subsystem for Unix-based applications is a Microsoft download. It means I can compile C programs using 'cc' or 'c89', and yep, it's VS behind that curtain. It's an alternative to MinGW or CygWin that might be worth exploring. Visual Studio remains a separate product, but SUA is free. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote: representation faults your program tried to do something meaningful but the system was unable to represent the result (integer overflow, upper case of ÿ in a Latin 1 system, floating point overflow on a non-IEEE system, c) Your program isn't *wrong* but you will still have to change it. It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error. That kind of attitude might have done very well in the 1960s. In an age when Intel have demonstrated 48 full x86 cores on a single chip, when it's possible to get a single-chip DSP with 240 cores that's fast enough to *calculate* MHz radio signals in real time, typical machine-oriented integer sizes run out _really_ fast. For example, a simple counting loop runs out in well under a second using 32-bit integers. The programmer doesn't always have the information necessary to choose machine-oriented integer sizes. Or it might not offer a choice. Or the choice the programmer needs might not be available: if I want to compute sums of products of 64-bit integers, where are the 128-bit integers I need? domain errors A precondition on the input arguments of an operation was not satisfied (e.g., X/0, sqrt(-1), malformed file name, head []). Your program is definitely wrong. X/0, sqrt(-1), head [] are errors It depends on WHERE THE DATA CAME FROM. Sure, the distinction exception/error depends on the source of the data that causes problems. And sadly, the library does not know this, so the library cannot classify problems _that_ way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, 8 Dec 2009, Ben Franksen wrote: Michael, Henning There are two meanings to the word 'exception' in this context; both of you tend to conflate these different meanings. One meaning is about a *mechanism* for non-local control flow; the other is about certain classes of un-desired program conditions. Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me. I'm actually arguing that errors and exceptions (or failures) should not be treated the same way. This is my opinion because 1. You cannot catch all kinds of errors (infinite loops, memory corruption, and so on) at run-time 2. The program cannot help itself if it is buggy. The next higher level in the software hierarchy certainly can, but this requires obviously a different mechanism. The correct treatment of those things is in my opion: 1. Errors must be fixed by the programmer 2. Exceptions must be appreciated by the programmer and handled by the program at runtime So, maybe it would help if we could agree to use different terms for those two meanings of the word 'exception'. I think 'exception' is too strongly associated with the non-local control flow mechanism to introduce a new word for it. I used the term exception because this is the term used for the concept of handling file not found, could not allocate resource in the introduction to modern languages that I have read. Thus my impression was that exception is the term for the concept, whereas there are different implementations and ways of handling them. For instance in Modula-3 the EXIT statement is called an exception that escapes the LOOP structure, but it cannot be catched with TRY, that is used for user defined exceptions. http://www.cs.purdue.edu/homes/hosking/m3/reference/exit.html In Modula-3 a detected error (range violation, NIL dereference, division by zero) terminates the program. An undetected error (which is restricted to UNSAFE modules) can cause memory corruption and all those bad things, and cannot be handled in any way. Before exceptions got a special handling in programming language, they still existed. In C for instance they were expressed by return codes. The Wikipedia author also seem to consider exception to be the term for the concept, not for the implementation: http://en.wikipedia.org/wiki/Exception_handling Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of exceptions, special conditions that change the normal flow of program execution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: binding to C libraries on Windoww
Robert Greayer wrote: It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'. They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix). The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio. These compilers are mostly C99 compliant, also unlike MS Visual Studio. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
On Tue, 8 Dec 2009, Richard O'Keefe wrote: is_Zumkeller :: Int - Bool is_Zumkeller n = let facs = factors n fsum = sum facs in mod fsum 2 == 0 I see this test is essential. I didn't do it and thus my program did not find that 1800 is not a Zumkeller number within an hour. With this check my program becomes dramatically faster. can_part facs (div fsum 2) main = print (filter is_Zumkeller [1..5000]) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, 8 Dec 2009, Richard O'Keefe wrote: X/0, sqrt(-1), head [] are errors It depends on WHERE THE DATA CAME FROM. If your program actually computes X/0 or sqrt(-1) or head [] your program is buggy, independent from where the zero, the minus one or the empty list comes. Sure, the distinction exception/error depends on the source of the data that causes problems. And sadly, the library does not know this, so the library cannot classify problems _that_ way. To this end the library documentation says: Precondition: This function must only be called on non-empty lists. If the programmer calls it with an empty list anyway, it's his fault. The library user made the error then. Of course it would be better, if types or contracts could force such restrictions: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068877.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, 8 Dec 2009, Richard O'Keefe wrote: On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote: It is the responsibility of the programmer to choose number types that are appropriate for the application. If I address pixels on a todays screen I will have to choose at least Word16. On 8-bit computers bytes were enough. Thus, this sounds like an error. That kind of attitude might have done very well in the 1960s. I don't quite understand. If it is not the responsibility of the programmer to choose numbers of the right size, who else? If the operating system uses Int32 for describing files sizes and Int16 for screen coordinates, I'm safe to do so as well. The interface to the operating system could use type synonyms FileSize and ScreenCoordinate that scale with future sizes. But the programmer remains responsible for using ScreenCoordinate actually for coordinates and not for file sizes. In an age when Intel have demonstrated 48 full x86 cores on a single chip, when it's possible to get a single-chip DSP with 240 cores that's fast enough to *calculate* MHz radio signals in real time, typical machine-oriented integer sizes run out _really_ fast. For example, a simple counting loop runs out in well under a second using 32-bit integers. The programmer doesn't always have the information necessary to choose machine-oriented integer sizes. Or it might not offer a choice. Or the choice the programmer needs might not be available: if I want to compute sums of products of 64-bit integers, where are the 128-bit integers I need? And the consequence is to ship a program that raises an exception about problems with the size of integers? I'm afraid I don't understand what you are arguing for. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
G'day all. Quoting Richard O'Keefe o...@cs.otago.ac.nz: These lines of Haskell code find the Zumkeller numbers up to 5000 in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took 1.1 seconds. Note that this just finds whether a suitable partition exists; it does not report the partition. This takes 0.1 seconds on a 2GHz Dell running Linux: module Main where import Control.Monad import qualified Data.List as L primesUpTo :: Integer - [Integer] primesUpTo n | n 13 = takeWhile (= n) [2,3,5,11] | otherwise = takeWhile (= n) primes where primes = 2 : 3 : sieve 0 (tail primes) 5 sieve k (p:ps) x = let fs = take k (tail primes) in [x | x-[x,x+2..p*p-2], and [x `rem` p /= 0 | p-fs] ] ++ sieve (k+1) ps (p*p+2) pseudoPrimesUpTo :: Integer - [Integer] pseudoPrimesUpTo n | n = wheelModulus = takeWhile (= n) smallPrimes | otherwise = smallPrimes ++ pseudoPrimesUpTo' wheelModulus where largestSmallPrime = 11 verySmallPrimes = primesUpTo largestSmallPrime wheelModulus = product verySmallPrimes smallPrimes = primesUpTo wheelModulus wheel = mkWheel 1 [1] verySmallPrimes mkWheel _ rs [] = rs mkWheel n rs (p:ps) = mkWheel (p*n) (do k - [0..p-1] r - rs let r' = n*k + r guard (r' `mod` p /= 0) return r') ps pseudoPrimesUpTo' base | n = base + wheelModulus = takeWhile (= n) . map (+base) $ wheel | otherwise = map (+base) wheel ++ pseudoPrimesUpTo' (base + wheelModulus) -- Integer square root. isqrt :: Integer - Integer isqrt n | n 0 = error isqrt | otherwise = isqrt' ((n+1) `div` 2) where isqrt' s | s*s = n n (s+1)*(s+1) = s | otherwise = isqrt' ((s + (n `div` s)) `div` 2) -- Compute the prime factorisation of an integer. factor :: Integer - [Integer] factor n | n = 0 = error factor | n = primeCutoff = factor' n (primesUpTo primeCutoff) | otherwise= factor' n (pseudoPrimesUpTo (isqrt n)) where primeCutoff = 100 factor' 1 _ = [] factor' n [] = [n] factor' n (p:ps) | n `mod` p == 0 = p : factor' (n `div` p) (p:ps) | otherwise = factor' n ps -- The only function used from above is factor. zumkeller :: Integer - Bool zumkeller n | isPrime= False | isPrime= False | sigma `mod` 2 == 1 = False | sigma 2*n= False | otherwise = sigmaTest ((sigma - 2*n) `div` 2) (factors n) where isPrime = case factorn of [_] - True _ - False factorn = factor n sigma = product . map (sum . scanl (*) 1) . L.group $ factorn factors n = reverse [ f | f - [1..n `div` 2], n `mod` f == 0 ] sigmaTest 0 _ = True sigmaTest _ [] = False sigmaTest n (f:fs) | f n = sigmaTest n fs | otherwise = sigmaTest (n-f) fs || sigmaTest n fs main = print (filter zumkeller [1..5000]) Yes, I cheated by using a different algorithm. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Dec 8, 2009, at 1:27 PM, Henning Thielemann wrote:
On Tue, 8 Dec 2009, Richard O'Keefe wrote:
On Dec 8, 2009, at 12:28 PM, Henning Thielemann wrote:
It is the responsibility of the programmer to choose number types
that are appropriate for the application. If I address pixels on a
todays screen I will have to choose at least Word16. On 8-bit
computers bytes were enough. Thus, this sounds like an error.
That kind of attitude might have done very well in the 1960s.
I don't quite understand. If it is not the responsibility of the
programmer to choose numbers of the right size, who else?
It is the responsibility of the computer to support the numbers
that the programmer needs. It is the responsibility of the computer
to compute CORRECTLY with the numbers that it claims to support.
I repeat: the programmer might not KNOW what the integer sizes are.
In Classic C and C89, the size of an 'int' was whatever the compiler
chose to give you. In c89, limits.h means that the program can find
out at run time what range it got, but that's too late.
If the operating system uses Int32 for describing files sizes and
Int16 for screen coordinates, I'm safe to do so as well.
In a very trivial sense, this is true.
In any less trivial sense, not hardly.
Suppose I am calculating screen coordinates using
/ x \ / a11 a12 a13 \ / u \
| y | = | a21 a22 a23 | | v |
\ 1 / \ 0 0 1 / \ 1 /
which is a fairly standard kind of transformation,
it is not in general sufficient that u, v, x, and y should all
fit into Int16. The intermediate results must _also_ fit.
(Assume for the moment that overflow is checked.)
If I need to represent *differences* of Int32 pairs, I know
perfectly well what type I need: Int33. But there is no such
type.
The interface to the operating system could use type synonyms
FileSize and ScreenCoordinate that scale with future sizes. But the
programmer remains responsible for using ScreenCoordinate actually
for coordinates and not for file sizes.
Consider this problem:
We are given a whole bunch of files, and want to determine
the total space used by all of them.
Smalltalk:
fileNames detectSum: [:each | (FileStatus fromFile: each) size]
The answer is correct, however many file names there are in the
collection. But if we're using C, or Pascal, or something like
that, we want to do
FileCollectionSize fcs = 0;
for (i = 0; i n; i++) {
fcs += OS_File_System_Size(filename[i]);
}
and how on earth do we compute the type FileCollectionSize?
Remember, it has to be big enough to hold the sum of the sizes of
an *unknown* and quite possibly large number of quite possibly
extremely large files, not necessarily confined to a single disc,
so the total could well exceed what will fit in FileSize.
This is especially so when you realise that there might be many
repetitions of the same file names. I can _easily_ set this up
to overflow 64 bits on a modern machine.
In Haskell, you'd want to switch straight over to Integer and
stay there.
In an age when Intel have demonstrated 48 full x86 cores on a single
chip, when it's possible to get a single-chip DSP with 240 cores
that's fast enough to *calculate* MHz radio signals in real time,
typical machine-oriented integer sizes run out _really_ fast.
For example, a simple counting loop runs out in well under a second
using 32-bit integers.
The programmer doesn't always have the information necessary to
choose machine-oriented integer sizes. Or it might not offer a
choice.
Or the choice the programmer needs might not be available: if I want
to compute sums of products of 64-bit integers, where are the 128-bit
integers I need?
And the consequence is to ship a program that raises an exception
about problems with the size of integers?
Yes. Just because the programmer has TRIED to ensure that all the
numbers will fit into the computer's arbitrary and application-
irrelevant
limits doesn't mean s/he succeeded. For that matter, it doesn't mean
that the compiler won't use an optimisation that breaks the program.
(Yes, I have known this happen, with integer arithmetic, and recently.)
I'm afraid I don't understand what you are arguing for.
I'm arguing for three things.
(1) If you look at the CERT web site, you'll discover that there have
been
enough security breaches due to integer overflow that they
recommend
working very hard to prevent it, and there's an As If Ranged
project
to enable writing C _as if_ it could be trusted to raise exceptions
about problems with the size of integers. It is better to raise an
exception than to let organised crime take over your computer.
(2) In a language like Ada where the programmer can *say* exactly what
range
they need, and the bounds can be computed at compile time, and the
compiler either does it right or admits right away that it can't,
it's
the programmer's fault if it's wrong.
Re: [Haskell-cafe] Hayoo and Hoogle (beginner question)
Thanks for all the answers, in particular the history (quoted) was informative! So for now the answer is indeed probably to use both, starting with Hoogle if I am searching by type. And if you do find that old hayoo command line search script yes please :P (esp the offline one, I do so much studying on airplanes that even if I couldn't download the package knowing I didn't need to build it myself would be great)! If I get irked enough at the browser to hack together a wget/cut/grep (or-dare-i-say-ruby) script to search hayoo from bash I will post it somewhere haskelly! Neil Mitchell wrote: Hi, It probably helps to know some of the history, as it explains a lot of what you see today. Hoogle was written first (about 5 years ago now), before there was hackage (so it doesn't search hackage), and with an emphasis on type search (as that's cool). Hayoo came a lot later (about 2 years ago at most). Hoogle will be gaining the ability to do a full search of Hackage - I'm just waiting to get some bits sorted out first. There isn't really a technical obstacle, I've just not had the time to finish the implementation. Use whichever you choose, but if you use Hayoo for some reason other than Hoogle not searching all packages, I'd love to know. Thanks, Neil 2009/12/7 drostin77 ml.nwgr...@gmail.com: Hello Hopefully Helpful Haskell Community! (I really wanted that to be alliteration... couldn't come up with an h word for community) I've just started learning Haskell (working my way through Real World Haskell and really liking it)! I have started to appreciate that there are a lot of Haskell libraries I will want to search and access quite regularly when I work on Haskell projects, so I had the following questions: 1. Hoogle and Hayoo: I'm a bit confused by the difference here. From initial impressions it seems that Hayoo is linked to Hackage, but Hoogle is not? And it seems that Hayoo is, well, Similar to Hoogle, but with less focus on type search. Should I check both of these when I want a library, or choose one and go with it...? Or is it indeed better to search Hayoo when I'm thinking of a named library and Hoogle when I think I know the type signature for just the function I need? 2. I much prefer a command line search interface to a browser, I see Hoogle offers such a tool, does Hayoo? P.S. If these questions are in the wrong place, or if they are already answered in detail somewhere that my Googling didn't find please feel free to paste a link and tell me to search better next time! -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26669924.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/Hayoo-and-Hoogle-%28beginner-question%29-tp26669924p26687210.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] Zumkeller numbers
Am Dienstag 08 Dezember 2009 01:54:12 schrieb a...@spamcop.net: G'day all. Quoting Richard O'Keefe o...@cs.otago.ac.nz: These lines of Haskell code find the Zumkeller numbers up to 5000 in 5 seconds on a 2.2GHz intel Mac. The equivalent in SML took 1.1 seconds. Note that this just finds whether a suitable partition exists; it does not report the partition. This takes 0.1 seconds on a 2GHz Dell running Linux: snip Yes, I cheated by using a different algorithm. Cheers, Andrew Bromage Yes, what I do (after fixing an embarrassing typo from the first post). Using Int, it's a little faster, with Integer the same time. I've now added the printout of one partition. module Main (main) where import Data.List (sort) import Control.Monad (liftM2) import System.Environment (getArgs) main = do args - getArgs let bd = case args of (a:_) - read a _ - 4000 mapM_ (\n - case zumParts n of [] - return () ((l,r):_) - putStrLn (show n ++ ++ show l ++ ++ show r)) [1 .. bd] trialDivPrime :: [Int] - Int - Bool trialDivPrime (p:ps) n = (p*p n) || (n `mod` p /= 0) trialDivPrime ps n oprs = 5:7:filter (trialDivPrime oprs) (scanl (+) 11 $ cycle [2,4]) primes :: [Int] primes = 2:3:oprs factors :: Int - [(Int,Int)] factors n | n 0 = factors (-n) | n == 0= [(0,1)] | otherwise = go n primes where go 1 _ = [] go m (p:ps) | p*p m = [(m,1)] | otherwise = case m `quotRem` p of (q,0) - case countFactors q p of (m',k) - (p,k+1):go m' ps _ - go m ps countFactors :: Int - Int - (Int,Int) countFactors n p = go n 0 where go m k = case m `quotRem` p of (q,0) - go q (k+1) _ - (m,k) divisors :: Int - [Int] divisors n = sort $ foldr (liftM2 (*)) [1] ppds where ppds = map (\(p,k) - take (k+1) $ iterate (*p) 1) $ factors n partition :: Int - [Int] - [[Int]] partition 0 _ = [[]] partition n [] = [] partition n (p:ps) | n p = partition n ps | otherwise = [p:parts | parts - partition (n-p) ps] ++ partition n ps zumParts :: Int - [([Int],[Int])] zumParts n | sigma 2*n = [] | odd sigma = [] | otherwise = [(prt ++ [n],init divs `without` prt) | prt - prts] where divs = divisors n sigma = sum divs target = (sigma-2*n) `quot` 2 sml = takeWhile (= target) $ init divs prts = map reverse $ partition target (reverse sml) xxs@(x:xs) `without` yys@(y:ys) | x y = x:xs `without` yys | x == y= xs `without` ys | otherwise = xxs `without` ys xs `without` _ = xs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
I'm wondering, what are we talking about here? - the meaning of error and exception? - personal responsibility when writing programs? - language features - library functions, runtime implementation etc.? The first two, I think could serve as the basis for an entertaining discussion. Where the third applies, if there are real disagreements it would be helpful to frame the discussion at least partly in those terms, so anyone who has a practical interest in the matter may understand what's being discussed. In my view, the discussion so far has shown that while everyone has interesting and valuable opinions about how various contingencies ought to be handled, in the end it no doubt it must be up to the programmer writing the code ... right? Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to deal with C buf in Haskell?
Hi,
I am warping some C libs. In one function, I do this:
183 allocaBytes bufLen $ \buf - do
184ret - {# call buf_read #}
185 bluh
186 bala
187 buf
188 bufLen
189if ret 0
190 then userError bufRead error
191 else -- what should I do here?
I am thinking about bytestring, to pass the content of the buf to
the outside of the function. But I am not sure.
What should I do?
--
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with C buf in Haskell?
On Tue, Dec 8, 2009 at 3:22 AM, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
Hi,
I am warping some C libs. In one function, I do this:
183 allocaBytes bufLen $ \buf - do
184 ret - {# call buf_read #}
185 bluh
186 bala
187 buf
188 bufLen
189 if ret 0
190 then userError bufRead error
191 else -- what should I do here?
I am thinking about bytestring, to pass the content of the buf to
the outside of the function. But I am not sure.
What should I do?
See: Data.ByteString.Internal.createAndTrim:
http://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html/Data-ByteString-Internal.html#v:createAndTrim
With that your program becomes something like:
createAndTrim bufLen $ \buf -
ret - {# call buf_read #}
bluh
bala
buf
bufLen
if ret 0
then userError bufRead error
else return ret -- if ret indicates the number of bytes read
regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Handles with their IOMode in their type
Could not get to sleep tonight so I got up and hacked this together: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13782 Does something like this already exist on hackage: If not, I may turn this into a package and upload it tomorrow. Comments, criticism and patches are welcome. regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
Nicolas Pouillard wrote: Excerpts from Henning Thielemann's message of Mon Dec 07 20:36:27 +0100 2009: @Apfelmus: For practical purposes I think Train should have swapped type parameters in order to make Functor act on the type of the list elements. data Train b a = Wagon a (Train b a) | Loco b The functor on the Loco/Caboose makes sense too and swapping the arguments is less natural to read. Indeed, Train is a bifunctor. Choosing one over the other is as arbitrary as choosing one over the other for (,) or Either. The only difference here is that the two functors aren't the same. There are reasons for wanting both instances depending on how the structure is being used. It's times like this that I wish Haskell had real type-level functions, at least for swap and compose, without the need for newtype wrappers or type-family peculiarities. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
On Sat, Dec 5, 2009 at 6:35 AM, Jasper van der Jeugt jasper...@gmail.com wrote: Hakyll is a simple static site generator library, mostly aimed at blogs. It supports markdown, tex and html templates. It is inspired by the ruby Jekyll program. It has a very small codebase because it makes extensive use of the excellent pandoc and Text.Template libraries. More information can be found on: http://hackage.haskell.org/package/hakyll-0.1 http://github.com/jaspervdj/Hakyll I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. I don't think you're alone in this — IIRC I've seen several Hackage libraries doing the same thing. I *really* wish Pandoc would switch to a non-copyleft license. (Pretty please, with sugar and cherries on top?) I know that GPL authors are trying to enforce contributions, but the opposite can very well happen: if you have an essential copyleft library, someone's eventually going to write a non-copyleft replacement for it (e.g., witness the replacements for Readline) rather than continue to allow it to restrict the licensing options of the community. Great libraries should be able to be embraced without reservations. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen ben.frank...@online.de wrote: Michael Snoyman wrote: On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 7 Dec 2009, Michael Snoyman wrote: I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. Firstly: I'm really referring exclusively to non-FFI Haskell programs, to which most of the issues you mention don't really apply. Nonetheless, I think that for a language with exceptions, it still makes sense to use the exceptions in these cases. In all these cases, I think the correct thing is to have a specific exception type that is thrown that signals that it is such an unrecoverable error. This allows the programmer to do *whatever* they want. Perhaps they want to save some other data to a file before exiting? Perhaps they want to spawn a process to send in a bug report? Who knows. It doesn't matter. The point is, the user *might* want to do something, and exceptions let them do it if they wish, or they can completely ignore that specific exception type and let the program crash anyway. Michael, Henning There are two meanings to the word 'exception' in this context; both of you tend to conflate these different meanings. One meaning is about a *mechanism* for non-local control flow; the other is about certain classes of un-desired program conditions. Actually, I think you'll find the we are *not* conflating the terms. Henning makes it clear later on. Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me. There are certainly good use cases, you have presented a few. However, that does not mean it is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and other kinds of expected exceptional conditions in general, as you claimed in a previous message. I agree with Henning insofar as I think it is important to make the *conceptual* distinction -- regardless of whether we use the same mechanism to signal (and, perhaps, after serious consideration, handle) them. So, maybe it would help if we could agree to use different terms for those two meanings of the word 'exception'. I think 'exception' is too strongly associated with the non-local control flow mechanism to introduce a new word for it. Henning, what about calling an undesired but expected condition a 'failure' instead of an exception, so we could reserve this word for the language mechanism? Calling something a 'failure' in this sense (i.e. in contrast to 'error') would always include some judgement, as it needs to take the different program levels into account. Please do *not* call them failures; a few of us have been working on a failure package and associated helper packages, and called it failure specifically because it was an unused term and thus incurred none of the wrath which rains down upon those unfortunate souls who conflate the terms error and exception in the descriptions of their issues. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lots of Haskell at PEPM 2010 - Call for Participation
Hi all, If you are planning to go to Madrid in January, for POPL, don't forget registering for PEPM as well! If you haven't yet been planning to go, maybe you want to reconsider, for PEPM if not for POPL. Why, you ask? Well, the PEPM program has *lots* of Haskell this year. Indeed, no fewer than 10 of the 21 presentations are directly related to Haskell. And the other papers are great, too, and many of them will be interesting to Haskell folk as well. Scan the speakers and titles below, and you will know why I think you won't want to miss out on that one. Best regards, Janis. === CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 === Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh. Optimizing Generics Is Easy! * Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero Júnior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Hackage category: Error Handling
On Tue, Dec 8, 2009 at 7:40 AM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Dec 8, 2009 at 1:25 AM, Ben Franksen ben.frank...@online.dewrote: Michael Snoyman wrote: On Mon, Dec 7, 2009 at 9:53 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 7 Dec 2009, Michael Snoyman wrote: I also think that in an earlier mail I answered, that errors can leave you with corrupt data, say invalid file handles, memory pointers, or data structures that violate invariants. You won't like to close files from invalid file handles and free memory from corrupt pointers or run into infinite loops by traversing the corrupt data structures. That's the reason why it is better to stop execution of the program and hand over control to the next higher level, say the shell or the web browser, that can free resources safely. Firstly: I'm really referring exclusively to non-FFI Haskell programs, to which most of the issues you mention don't really apply. Nonetheless, I think that for a language with exceptions, it still makes sense to use the exceptions in these cases. In all these cases, I think the correct thing is to have a specific exception type that is thrown that signals that it is such an unrecoverable error. This allows the programmer to do *whatever* they want. Perhaps they want to save some other data to a file before exiting? Perhaps they want to spawn a process to send in a bug report? Who knows. It doesn't matter. The point is, the user *might* want to do something, and exceptions let them do it if they wish, or they can completely ignore that specific exception type and let the program crash anyway. Michael, Henning There are two meanings to the word 'exception' in this context; both of you tend to conflate these different meanings. One meaning is about a *mechanism* for non-local control flow; the other is about certain classes of un-desired program conditions. Actually, I think you'll find the we are *not* conflating the terms. Henning makes it clear later on. Let me rephrase that: we both agree that there is at least a theoretical difference between the two. I believe the distinction in practice is difficult, if not possible, to determine, while Henning disagrees (I believe). Since I believe the two cannot in general be distinguished by name, they should not be distinguished by mechanism, and thus individual types of errors/exceptions/failures should be distinguished by type. I believe Henning thinks that errors should cause a program to abort, while exceptions should be handled by the exception mechanism. So you're right: we do conflate the terms a bit. I *think* the conflation in terminology, however, is directly correlated to the conflation in mechanism. Michael, you are above arguing that it is ok to use the same /mechanism/ to signal errors and exceptions. That is ok with me. There are certainly good use cases, you have presented a few. However, that does not mean it is 'silly' or 'unnecessary' to distinguish between program(-mer) errors and other kinds of expected exceptional conditions in general, as you claimed in a previous message. I agree with Henning insofar as I think it is important to make the *conceptual* distinction -- regardless of whether we use the same mechanism to signal (and, perhaps, after serious consideration, handle) them. So, maybe it would help if we could agree to use different terms for those two meanings of the word 'exception'. I think 'exception' is too strongly associated with the non-local control flow mechanism to introduce a new word for it. Henning, what about calling an undesired but expected condition a 'failure' instead of an exception, so we could reserve this word for the language mechanism? Calling something a 'failure' in this sense (i.e. in contrast to 'error') would always include some judgement, as it needs to take the different program levels into account. Please do *not* call them failures; a few of us have been working on a failure package and associated helper packages, and called it failure specifically because it was an unused term and thus incurred none of the wrath which rains down upon those unfortunate souls who conflate the terms error and exception in the descriptions of their issues. Michael Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hakyll-0.1
Okay, You're right. I will change the license info as soon as possible. Kind regards, Jasper Van der Jeugt On Dec 8, 2009 6:30 AM, Tom Tobin korp...@korpios.com wrote: On Sat, Dec 5, 2009 at 6:35 AM, Jasper van der Jeugt jasper...@gmail.com wrote: Hakyll is a simp... I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. I don't think you're alone in this — IIRC I've seen several Hackage libraries doing the same thing. I *really* wish Pandoc would switch to a non-copyleft license. (Pretty please, with sugar and cherries on top?) I know that GPL authors are trying to enforce contributions, but the opposite can very well happen: if you have an essential copyleft library, someone's eventually going to write a non-copyleft replacement for it (e.g., witness the replacements for Readline) rather than continue to allow it to restrict the licensing options of the community. Great libraries should be able to be embraced without reservations. ___ 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] ANN: hakyll-0.1
Tom Tobin wrote: I hate to say this, but it looks like you're violating the GPL by not releasing Hakyll under the GPL, since Pandoc is GPL'd. Not necessarily. The 3 clause BSD license is officially a GPL compatible license. See: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It is within the terms of the GPL to link GPL code to a bunch of BSD3 code as long as you abide by both the GPL and the BSD3 license. Hakyll would only run into trouble if it was used as a library that linked to code which was not under a GPL compatible license. I *really* wish Pandoc would switch to a non-copyleft license. The LGPL is still a copyleft license. Do you still have a problem with that? (Pretty please, with sugar and cherries on top?) Most chunks of code can't switch license because they have dozens of contributions from dozens of people many of whom they no longer have contact with. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Zumkeller numbers
Richard O'Keefe o...@cs.otago.ac.nz writes: factors n = [m | m - [1..n], mod n m == 0] -- saves about 10% time, seems to give the same result: factors n = [m | m - [1..n `div` 2], mod n m == 0]++[n] (But checking against primes is even faster, it seems) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
