Re: [Haskell-cafe] STM: nested atomically error
On 12/01/2012 12:48 PM, Johan Brinch wrote: I'm not using any unsafe IO OK, good... (only for debug printing) ...ah. It seems we have reached a contradiction. Where is a transaction being nested? My guess is that your debug printing is causing something to be evaluated when it otherwise wouldn't be, causing a transaction to begin within a transaction. I could, however, be horribly wrong about that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Sorry to say, but it seems you yourself are unaware of the extensive and highly flexible locking facilities on Linux :) The defaults on Linux are advisory locking, not mandatory, but claiming Linux doesn't support locking is plain wrong. I would suggest that advisory locking isn't particularly useful. I gather that Linux does now support real locking though. (And file update notifications, and ACLs, and lots of other things that Windows has had for far longer.) Either way, I have no interest in starting a Windows vs Linux flamewar. I'm just saying it would be nice if Haskell could support more of what these two OSes have to offer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
I gather that Linux does now support real locking though. (And file update notifications, and ACLs, and lots of other things that Windows has had for far longer.) Hrmm: Mandatory File Locking For The Linux Operating System, 15 April 1996 :) Have a reference for when it was actually implemented? I tried to look this up, and got this: http://0pointer.de/blog/projects/locking.html Sounds like it's not so solved after all. (Or perhaps the author just doesn't know enough about it, it's hard to say...) The Wikipedia page on file locking also points out a list of Unix-related locking problems. (But again, that might just be editor bias.) I'm just saying it would be nice if Haskell could support more of what these two OSes have to offer. Totally agreed! Good, that was my main point. Now, who's volunteering to implement all this? :-} ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows: openFile gives permission denied when file in use
On 29/12/2011 04:29 AM, Antoine Latter wrote: On Wed, Dec 28, 2011 at 3:52 PM, Michael Snoymanmich...@snoyman.com wrote: Hi all, I just received a bug report from a client that, when an input file is open in FrameMaker, my program gives a permission denied error. This bug is reproducible with a simple Haskell program: This bug and its discussion is similar, but not identical: http://hackage.haskell.org/trac/ghc/ticket/4363 This one has been rumbling on for ages. As others have said, the Report demands that locking occur, which is probably a mistake. The daft thing is, apparently Linux doesn't really support locking, so on that platform these types of thing all work fine, and only on Windows, which does and always has supported propper locking, people get these errors. And yet, many people seem surprised to hear that Windows can actually turn off the locking; they seem completely unaware of the extensive and highly flexible locking facilities that Windows provides. Every time I hear oh, I don't think Windows can handle that, I sigh with resignation. Whatever we change the default to, it would be useful if we could expose locking mechanisms in a reasonably portable way so that people who care about such things can alter the default if it is not what they want. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On 19/12/2011 07:20 PM, Robert Clausecker wrote: Image you would create your own language with a paradigm similar to Haskell or have to chance to change Haskell without the need to keep any compatibility. What stuff would you add to your language, what stuff would you remove and what problems would you solve completely different? 1. Remove special treatment for lists. That is, remove the standard list type from the Prelude and make it into just another container library. The type is trivially definable; it doesn't need to be hard-wired into the language. I would name it List rather than [] too, and give its constructors sensible names rather than : and []. I would also make the current literal list syntax overloaded, so it can be used to construct any type of container. (Much the way numeric literals are overloaded.) 2. Add special treatment for arrays. That is, have strict, unboxed arrays hard-wired into the language. For every user type, not just ones which are members of a special type. Fully parametric. You know, like how they are in almost every other programming language known to Man, except Haskell. Also, the base array library would have zero-based integer indicies, and if you want arbitrary index values, that would be a library on top. Also, primitives for fast copying of array chunks. 3. Fix the Typeclassopedia. By which I mean things like removing fail from Monad, making Applicative a superclass of Monad, etc. You know, the usual stuff everybody complains about for being horribly broken. 4. Do something sane with the numerical classes. Unfortunately, this one is a Hard Problem. I doubt you can solve this without rampant language changes. But it should be possible to /improve/ on what exists currently. 5. Miscelaneous consistency changes. Haskell has a number of minor glitches which are irritating though not catastrophic. Things like type signatures being allowed in expressions but not patterns. Value constructors can be operators, but type constructors cannot. Negation is the only unary operator. And so forth. Nothing radical here. 6. Experimental stuff. I have a number of other, more radical ideas, but I probably wouldn't put those in, because the resulting language would be so drastically different that it wouldn't be Haskell any more. (That said, most of the stuff above would pretty much be hard breaking changes...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On 21/12/2011 10:09 AM, Jesse Schalken wrote: IIRC, Scite's default configuration is with non-monospace font. I actually found it quite appealing, and in fact forgot about it entirely after some usage. It is much easier on the eyes to read. The difference is really whether you care about aligning things mid-line or not, not to mention editor support (i.e. not Vim or other terminal-based editor). SciTE's default binding /is/ proportional, not mono-space. I find it ever so irritating. Then again, I'm sure this one comes squarely down to personal preference, so it seems pointless to debate it. LaTeX offers the possibility of mid-line alignment even if you don't use monospace - a feature which I haven't seen in any other text processing system. It's a pitty this isn't more widespread... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What happens if you get hit by a bus?
On 16/12/2011 07:05 PM, Bardur Arantsson wrote: Michael Litchard wrote: [--snip--] If getting hit by a bus is a significant factor in the overall outcome of the project then I think those are pretty good odds, aren't they? (I do realize that traffic accidents are a lot more frequent than we like to think, but still...) The /actual/ probability of being hit by a bus is irrelevant. The only thing of concequence is the /percieved/ probability. This latter quantity is not related to the former in any meaningful way. In fact, due to an effect known as availability bias, the probability of any potential threat varies depending on how long you spend thinking about it. (In other words, if you've never even considered what would happen if your sole developer got hit by a bus, your estimate of the probability of this will be very low. If you sit down and think about how much trouble you'd be in if this actually happened, suddenly your estimate of the probability starts increasing. This is completely illogical - which is why it's called a cognitive bias.) Ever heard the phrase fear, uncertainty and doubt? It's a killer in a business context. It seems clear [to me] that there are actually quite a few Haskell programmers around, and it's not especially hard to find them. The question is how many good ones there are. Good is all vague and subjective and hard to measure, unfortunately. On the other hand, if you just start the project with more than one developer on board in the first place, then the possibility of just one of them being killed prematurely becomes drastically less serious. (For the business. I'm sure it's still fairly serious for the person who just DIED...) PS. Kudos to Ketil Malde for the best link I've seen today. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] XML modification
Hi guys. I've got a folder with about 80 XML files in it. I want to take each file and make specific modifications to it. (Mostly just finding specific attributes and changing their values to make then all consistent.) Now I guess it wouldn't take me /that/ long to code something from scratch. But does anybody have a better suggestion for tools or libraries that might be useful? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XML modification
On 23/11/2011 10:14 AM, Jon Fairbairn wrote: Andrew Coppinandrewcop...@btinternet.com writes: I've got a folder with about 80 XML files in it. I want to take each file and make specific modifications to it. HaXml Mmm. That looks very promising... which gives some idea of the flavour. OK. So it looks like processXmlWith is the function I want, if I'm going to read one file and create another from it. So now I just need to figure out which combinators I need. (The documentation seems a bit thin.) Can you show me a snippet for how I would find [one] element named foo and change its bar attribute to have the value 5? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XML modification
On 23/11/2011 12:58 PM, Andrew Coppin wrote: On 23/11/2011 10:14 AM, Jon Fairbairn wrote: HaXml Mmm. That looks very promising... which gives some idea of the flavour. OK. So it looks like processXmlWith is the function I want, if I'm going to read one file and create another from it. So now I just need to figure out which combinators I need. (The documentation seems a bit thin.) Can you show me a snippet for how I would find [one] element named foo and change its bar attribute to have the value 5? Well, from what I've been able to gather, HaXml has a really nice filter combinator library. However... Weird thing #1: processXmlWith handles the common case of loading a file from disk, filtering it, and saving the result to disk again. However, it does this based on CLI arguments. There is no function anywhere that I can find which allows the host program to specify what files to process. If you want to do that, you have to reimplement most of the body of this function all over again yourself. That seems a strange omission. Weird thing #2: There are absolutely no filters for dealing with attributes. I couldn't find anything anywhere that says apply this function to all the attributes of this element. I can find a function to /replace/ an element's attributes without regard to what existed before. But even something as trivial as adding an additional attribute while keeping the existing ones doesn't appear to be supported at all. Fortunately it turns out to not be especially hard to read the source for the replace-attributes function and change it to do what I want. But, again, it seems a rather large and obvious ommission. (I'm guessing that since attributes are key/value pairs and not content, you would need a seperate attribute filter type, which is different from the existing content filters. Even so, it shouldn't be /that/ hard to do...) Anyway, the important thing is, Haskell (and more specifically HaXml) let me accomplish the task I wanted without too much fuss. It's /certainly/ faster than editing 80 files by hand in a text editor! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 16/11/2011 04:50 AM, heathmatlock wrote: On Tue, Nov 15, 2011 at 10:18 PM, John Meacham j...@repetae.net mailto:j...@repetae.net wrote: People tend to concentrate on the lambda which cooresponds to the functional aspect of haskell when designing logos. Not nearly enough attention is paid to the other striking feature, the laziness. The 'bottom' symbol _|_ should feature prominently. The two most defining features of haskell are that it is purely functional and _|_ inhabits every type. The combination of which is very powerful. John I would have to think about this a bit longer, but here's the symbol reworked onto the helmet: http://i.imgur.com/ZziGQ.png If you're going to draw a piece of graphics, why use ASCII workarounds like _|_, when you can use the real thing (i.e., ⊥)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to represent such polymorphism?
On 04/10/2011 07:08 AM, Dominique Devriese wrote: All, In case anyone is interested, I just want to point out an interesting article about the relation between Haskell type classes and C++ (overloading + concepts): http://sms.cs.chalmers.se/publications/papers/2008-WGP.pdf Dominique Thanks for that. A very interesting read... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to represent such polymorphism?
On 02/10/2011 02:04 PM, Du Xi wrote: --It still didn't compile. I think the reason is that the following is disallowed: f::a-b f x = x The type a - b doesn't mean what you think it does. It does /not/ mean that f is allowed to return any type it wants to. It means that f must be prepaired to return any type that /the caller/ wants it to. So, given ANY POSSIBLE INPUT, the function must be able to construct a value of ANY POSSIBLE TYPE. This is, of course, impossible. The only way you can implement a function with this type signature is to cheat. Also, you can't just take x, which has type a, and then pretend that it has type b instead. Haskell doesn't work like that. Your type signature says that the result type can be different than the input type, but your function definition forces the result to always be /the same/ type as the input. Hence, it is rejected. That aside, the fundamental problem here is that each tuple type is a different, completely unrelated type, as far as the type system is concerned. (x,y) and (x,y,z) might look similar to you, but to the type system they're as similar as, say, Either x y and StateT x y z. In Haskell, the only way to get a function to work for several unrelated types (but not /every/ possible type) is to use classes. Depending on exactly what you're trying to do, you might be better using lists, or perhaps some custom data type. It depends what you want to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to represent such polymorphism?
On 02/10/2011 07:15 PM, Du Xi wrote: I guess this is what I want, thank you all. Although I still wonder why something so simple in C++ is actually more verbose and requires less known features in Haskell...What was the design intent to disallow simple overloading? In C++, the code is inferred from the types. (I.e., if a function is overloaded, the correct implementation is selected depending on the types of the arguments.) In Haskell, the types are inferred from the code. (Which is why type signatures are optional.) Really, it's just approaching the same problem from a different direction. Also, as others have said, you're probably just approaching the problem from the wrong angle. You don't design an object-oriented program the same way you'd design a procedural program; if you do, you end up with a horrible design. Similarly, you don't design a functional program the same way you would design an object-oriented one. It takes time (and experience) to figure out how to approach FP - or any other radically different paradigm, I suppose... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.IArray rant
It's rather that some considered the IArray API to be inadequate most of the time. Really, H98 arrays aren't very good at anything they do. For collective operations, you are supposed to convert the array to a list, work on the list and then convert it back to an array which just seems wrong. I am unconvinded that this is any more wrong than using a for loop in an imperative language. Remember that the lists are lazy, so it’s misleading to say “convert the array to a list” since what happens most of the time is that elements are taken out of the array and passed to the processing function and then thrown away before the next element is processed. You're still needlessly allocating and then garbage collecting memory though. My personal feeling is that Haskell programmers use lists a lot when what they really want are streams (in the sense of the stream-fusion library). I don't want you to actually *make* a physical list, I just want to abstract over something that sequentially generates data. But then, lists are in the standard Prelude, and hard-wired into the language syntax. Streams aren't exposed by any moderately standard library. Even the stream-fusion library treats streams as a sort of under the covers thing to deforest lists. My humble opinion is that half the time when people create physical lists, what they really mean is a data pipeline that doesn't need to physically materialise at all. But anyway... Haskell '98 arrays may have fancy indexing, but I've always wished that there had been a plain ordinary integer-indexed array construct, with the fancy indexing implemented on top of that, so your use of fancy indexing is /optional/. I get the distinct impression that the default array libraries are so barren just because nobody really used them much, and that was then and this is now, and it's a major pain to break something that so much code is written against... I just hope we don't end up with a bazillion different array implementations popping up. But we'll see. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Off-topic: Mathematics
On 30/08/2011 09:49 PM, Jerzy Karczmarczuk wrote: Knuth admitted that he had learnt a lot while teaching things he already knew. So did Feynman. And Landau. As counter-intuitive as it may seem, explaining something to somebody else forces you to order your thoughts and think through the knowledge you already have, so that you can present it to somebody else in something resembling a coherant form. It's not unusual for this process to clarify your own knowledge. At least, that's *my* excuse for constantly talking to myself... _ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Off-topic: Mathematics and modesty
On 30/08/2011 07:58 PM, Jerzy Karczmarczuk wrote: I think I know several mathematicians who learning that a person asking for help begins with trying to distinguish between knowledgeable, and those who just think they are, will simply - to say it politely - refuse to engage. I didn't intend to sound snobbish. It's just that there are people who will have read about XYZ in a book one time, and there are people who actually use XYZ every day of their working lives. The latter probably know a tad more about it. That's all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Off-topic: Mathematics
On 29/08/2011 01:13 PM, Christopher Done wrote: There's also #math on freenode, but it's a scary wilderness. On 29 August 2011 13:34, Benedict Eastaughionf...@gmail.com wrote: On 29 August 2011 09:34, Andrew Coppinandrewcop...@btinternet.com wrote: This is fairly wildly off-topic but... does anybody know of a good forum where I can ask questions about mathematics and get authoritative answers? Apart from math.stackexchange.com and mathoverflow.net, which people have already mentioned, people often discuss mathematics on #haskell-blah on Freenode. I know of several places where I can ask maths questions and half a dozen people will take guesses at what the correct solution might be. I haven't yet found anywhere where I can say when would a chi-squared test be more appropriate than a KS test? and get an informed, knowledgeable answer. (Answers from people who /know/ what they're talking about rather than just /think/ they know.) Anyway, from this thread I've got the names of a few places to start looking. And that's really what I was hoping for. Thanks for the tips. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
I meant if you're trying to *implement* serialisation. The Bits class allows you to access bits one by one, but surely you'd want some way to know how many bits you need to keep? I think that falls into the realm of protocol design; if you're doing it in your program at runtime, you're probably doing it wrong. (The fixed size version makes sense for marshaling; it's *dynamic* sizes that need to be thought out beforehand.) If you're doing, say, cryptography, then thousand-bit random integers that need to be serialised are fairly common... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On 29/08/2011 09:00 AM, Brandon Allbery wrote: On Mon, Aug 29, 2011 at 03:40, Andrew Coppin andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote: I meant if you're trying to *implement* serialisation. The Bits class allows you to access bits one by one, but surely you'd want some way to know how many bits you need to keep? I think that falls into the realm of protocol design; if you're doing it in your program at runtime, you're probably doing it wrong. (The fixed size version makes sense for marshaling; it's *dynamic* sizes that need to be thought out beforehand.) If you're doing, say, cryptography, then thousand-bit random integers that need to be serialised are fairly common... Sure, and there are encodings that let you do this without needing bitSize (BER). You need a word count, but that's usually part of the structure holding the integer. OK. But since there's no way of getting a byte count for an Integer either... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Off-topic: Mathematics
This is fairly wildly off-topic but... does anybody know of a good forum where I can ask questions about mathematics and get authoritative answers? (Apart from go visit the nearest university, that is.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On 26/08/2011 10:51 PM, Steve Schafer wrote: On Fri, 26 Aug 2011 20:30:02 +0100, you wrote: You wouldn't want to know how many bits you need to store on disk to reliably recreate the value? I can't say that I have cared about that sort of thing in a very long time. Bits are rather cheap these days. I store data on disk, and the space it occupies is whatever it is; I don't worry about it. I meant if you're trying to *implement* serialisation. The Bits class allows you to access bits one by one, but surely you'd want some way to know how many bits you need to keep? Likewise, you say the standard PRNG can be used to generate random Integers, but what if you're trying to implement a new PRNG? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On 26/08/2011 02:40 AM, Daniel Peebles wrote: And as Daniel mentioned earlier, it's not at all obvious what we mean by bits used when it comes to negative numbers. I guess part of the problem is that the documentation asserts that bitSize will never depend on its argument. (So would will write things like bitSize undefined :: ThreadID or similar.) I can think of several possible results one might want from a bit size query: 1. The number of bits of precision which will be kept for values of this type. (For Word16, this is 16. For Integer, this is [almost] infinity.) 2. The amount of RAM that this value is using up. (But that would surely be measured in bytes, not bits. And processor registors make the picture more complicated.) 3. The bit count to the most significant bit, ignoring sign. 4. The bit count to the sign bit. Currently, bitSize implements #1. I'm not especially interested in #2. I would usually want #3 or #4. Consider the case of 123 (decimal). The 2s complement representation of +123 is ...000011 The 2s complement representation of -123 is ...111101 For query #3, I would expect both +123 and -123 to yield 7. For query #4, I would expect both to yield 8. (Since if you truncate both of those strings to 8 bits, then the positive value starts with 0, and the negative one start with 1.) Then of course, there's the difference between count of the bits and bit index, which one might expect to be zero-based. (So that the Nth bit represents 2^N.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bitSize
On 26/08/2011 07:36 PM, Steve Schafer wrote: On Fri, 26 Aug 2011 18:24:37 +0100, you wrote: I would usually want #3 or #4. Out of curiosity, what for? While I do occasionally need to get a logarithmic size estimate of a number (which is basically what #3 and #4 are), the specific requirements in each case tend to vary, enough so that it's unlikely that a single function (other than simply taking the logarithm) can handle the majority of applications. You wouldn't want to know how many bits you need to store on disk to reliably recreate the value? Or how many bits of randomness you need to compute a value less than or equal to this one? I suppose I could use a binary logarithm. I'm just concerned that it would be rather slow. After all, I'm not interested in the exact logarithm (which is fractional), just the number of bits (which is a small integer)... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do-re-mi
On 25/08/2011 02:59 AM, Albert Y. C. Lai wrote: do, a block, a monad block rec, a knot tied in the block mu, a name that calls itself (mu is pronounced as me in modern Greek) forM_, a long long list to run SO, a state aborting threads (SO is stack overflow) la, a state to follow SO T's, tranformers of monads that will bring us back to do That's genius! :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] bitSize
Quoting the Haddock documentation for Data.Bits.bitSize: Return the number of bits in the type of the argument. The actual value of the argument is ignored. The function bitSize is undefined for types that do not have a fixed bitsize, like Integer. Does anybody else think it would be *far* more useful if bitSize applied to an Integer would tell you how many bits that particular Integer is using? Especially given that it can vary? Is there a way to actually determine how many bits are in an Integer? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance of concurrent array access
On 23/08/2011 09:04 PM, Andreas Voellmy wrote: I compiled this with ghc --make -rtsopts -threaded -fforce-recomp -O2 DirectTableTest.hs. Running time ./DirectTableTest 1 +RTS -N1 takes about 1.4 seconds and running time ./DirectTableTest 2 +RTS -N2 take about 2.0 seconds! I found that changing the array type used in the implementation of DirectAddressTable from IOArray to IOUArray fixes this problem. With this change, the running time of time ./DirectTableTest 1 +RTS -N1 is takes about 1.4 seconds whereas the running time ./DirectTableTest 2 +RTS -N2 is about 1.0 seconds. Increasing to 4 cores gives a run time of 0.55 seconds. Finally, I tried one more variation. Instead of having the threads work on the same shared array, I had each thread work on its own array. This scales nicely (as you would expect), more or less like the second program, with either IOArray or IOUArray implementing the DirectAddressTable data structure. I understand why IOUArray might perform better than IOArray, but I don't know why it scales better to multiple threads and cores. Does anyone know why this might be happening or what I can do to find out what is going on? I haven't deeply studied your code. However, I'm going to take a guess this has to do with strictness. By using an IOArray, you're probably filling each cell with a reference to drop 7 cyclicChars or similar, which then only gets evaluated (in one thread) when you call print. By using an IOUArray, you're definitely forcing each character to be computed right away, by the thread doing the writing. That's /probably/ what the difference is. As a guess. (Not sure how you can easily prove/disprove the theory though.) You don't say which GHC version, but AFAIK recent releases of GHC have a seperate heap per thread (or was it per capability?), which probably makes a difference if you start giving each thread its own array. That and just plain ordinary cache coherance issues... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Potential problem with AC-Vector-Fancy package
I think I have found a problem with the union function: If you look here: http://hpaste.org/49889 You will see that line 4 gives a different result to lines 6, 8, 10; this shouldn't be the case because union is commutative. AC-Vector-Fancy is merely a fancy facard over AC-Vector. So the bug is actually with AC-Vector. Looking at my source code, the true bug is in Data.BoundingBox.Range [which provides the engine that all the other bounding box types use). The actual bug turns out to by face-slappingly stupid: it's a typo in one of the variable names. I'll go get that fixed... and then maybe write some QuickCheck properties. I just updated AC-Vector 2.3.2, which fixes the bug. Sorry about that... Let me know if you find any other stupid mistakes. (Or even clever ones, but I rather doubt that!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Potential problem with AC-Vector-Fancy package
On 10/08/2011 11:04 PM, Dave Tapley wrote: Is anyone maintaining the AC-Vector-Fancy package? I haven't had a reply from the latest maintainer (Andrew Coppin) on Hackage, so I thought I'd open it up to cafe: Oh, right. I haven't checked my mailbox recently... I think I have found a problem with the union function: If you look here: http://hpaste.org/49889 You will see that line 4 gives a different result to lines 6, 8, 10; this shouldn't be the case because union is commutative. AC-Vector-Fancy is merely a fancy facard over AC-Vector. So the bug is actually with AC-Vector. Looking at my source code, the true bug is in Data.BoundingBox.Range [which provides the engine that all the other bounding box types use). The actual bug turns out to by face-slappingly stupid: it's a typo in one of the variable names. I'll go get that fixed... and then maybe write some QuickCheck properties. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: Issue 187
On 23/06/2011 11:30 PM, Jack Henahan wrote: My solution for the '[0] with a link far down the page' issue is just to search for '[0]'. My solution is to never read the text version and only ever read the HTML version. Works great for me. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.3 / Win32: Data.Time library?
On 14/06/2011 01:41 PM, Dmitri O.Kondratiev wrote: Yes, thanks. I just wonder why documentation for this particular module (Data.Time) is missing from GHC, 7.0.3 Haskell Hierarchical Libraries documentation generated for Win32. Really strange ... There are several packages that come with GHC, but don't show up in the Win32 library index. I don't know why, but it's been happening for a long time now. Apparently this is supposed to be fixed soon though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal fail
How do you make Cabal fail? Let me clarify. I built a package that uses a post-configure hook to do some settings detection. Under certain circumstances, it can fail. When this happens, the hook prints fatal error and quits. Unfortunately, I didn't actually /test/ whether it works. On further investigation, I discovered that the hook considers itself to have failed, but it doesn't bother actually telling Cabal about this. (!) So Cabal still thinks everything went fine. OK, so, let's the correct way to notify Cabal that we need to retry the configure step? I can't figure it out from the minimal documentation in Distribution.Simple. (I'm guessing I need to use a pre-configure hook, since by the time post-configure runs, the configure stage is presumably over...?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How do you test a parser?
OK, so suppose you sit down and write a complicated string parser. Now how do you test that it works correctly? One way is to run the parser over a large corpus of real world samples. This has a number of problems: * If the parser is for a grammar you just invented yourself, presumably no real world corpus exists yet. * This tests that the most commonly used features work OK, but might not test whether more obscure features work right. * There's no really obvious way to check that what the parser returns is /correct/. You've got the input, but there's nothing to compare with. * This probably doesn't test whether the parser /fails/ for invalid input, since a real world corpus would presumably consist entirely of valid input. Most people's library of choice appears to be QuickCheck. But while it's not hard to have QuickCheck generate random strings and confirm that the returned parse tree (if any) doesn't violate any invariants, it's not so easy to check that the parse tree is actually what it should be. On top of that, depending on what the grammar is, the vast majority of random strings are probably just parse failures. Even if they aren't, there are probably specific constructs that are special-cased in the parser, which are very unlikely to appear by chance. (Things like keyword names, special combinations of punctuation, etc.) You can try to write your own text generator that constructs text more closely approximating what your parser is supposed to parse. But then how do you tell whether your generator is right? If you have a function that turns a parse tree back into text again, you can try verifying that a round-trip is the identity function. Except perhaps sometimes it isn't. Perhaps a given expression has more than one equivalent representation. A round-trip from string and back again is even less likely to be stable. So what's the best way to attack this problem? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 10/06/2011 01:44 AM, Jason Dagit wrote: On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) Really? I found this in the manual so I think either the docs need to be updated or you are mistaken: Apparently I am mistaken. It allows inline C-- (as of 6.12.1): http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/ffi.html#ffi-prim Of course, C-- is not nearly the same as Core. Sorry about that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 09/06/2011 06:54 AM, Scott Lawrence wrote: On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) The general register naming scheme on x86 is: AL, AH: 8 bits AX: 16 bits EAX: 32 bits RAX: 64 bits There's a lot of code there, but from what I can see, it's all operating on 32-bit registers. So I'd say this is 32-bit code. On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would... (I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would... (I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.) For a chess engine this is for sure not true. I guess that this is one of very few domains where it really matters! The most (basic) operations with bitboards are anding, oring, xoring, shifting and (for magic bitboards) multiplying 64 bits values. When using 32 bits you need for some of these more then double time to achieve the same. I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower. Back in the old days of non-pipelined, uniscalar CPUs, it would certainly have been the case. Today's processors are far more complex than that. Things like cache misses tend to have a way, way bigger performance hit than anything arithmetic-related. I was wondering if there is a possibility to support 64 bit native codes without other stuff (calling conventions, win64 specific system calls etc). This could be perhaps a first step to full 64 bit support. But from the code of ghc I could not understand what this would mean. I'm wondering if you could write the operations you want is small C stub functions, and FFI to them and do it that way. I don't really know enough about this sort of thing to know whether that'll work... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 09/06/2011 08:44 PM, austin seipp wrote: On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin andrewcop...@btinternet.com wrote: I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower. The problem is you're probably going to need to spill things (somewhere) in order to operate on the upper 32bits of any given register in the non trivial case. x86 already is pathetic in its 8 GP registers. amd64 brings it up to 16. Well, that's true enough. Given that AMD64 adds more registers, I'm surprised that this apparently makes such a small difference to wall-clock run-times. (But perhaps it makes a bigger difference for GHC. I don't know.) I'm wondering if you could write the operations you want is small C stub functions, and FFI to them and do it that way. I don't really know enough about this sort of thing to know whether that'll work... It's highly unlikely that the cost of a foreign call (even an unsafe one) in terms of just CPU cycles will be cheaper than executing a few primitive arithmetic ops on the CPU. Yeah, you're probably right there actually. Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 06/06/2011 09:34 PM, Nicu Ionita wrote: Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subcategories on Hackage
On 05/06/2011 06:55 AM, Evan Laforge wrote: I don't think a hierarchy would have helped in this case, but tags would be appropriate. Actually, I wound up using the categories like tags. I think we just need better search, e.g. +tag +tag or something. +1 to all of the above. Also, I don't think listing every package on all of Hackage in one giant page is very useful any more. (I gather it was only meant to be a temporary interface in the first place...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: mecha-0.0.5
On 04/06/2011 08:25 PM, Tom Hawkins wrote: What is the easiest way to generate polygon meshes from constructive solid geometry? Marching cubes [4] seems pretty involved. As I understand it, this is a Very Hard Problem. This is (one of the reasons) why there are so few converters from POV-Ray to mesh-based formats; it's highly non-trivial to tesselate CSG. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: mecha-0.0.5
As I understand it, this is a Very Hard Problem. This is (one of the reasons) why there are so few converters from POV-Ray to mesh-based formats; it's highly non-trivial to tesselate CSG. POV-Ray is pretty fast. I had contemplated just rendering a bunch of POV-Ray images to emulate a realtime 3D view. Images could be buffered up based on the current camera position. That's an... interesting way of doing it. It's probably easier to build a simple renderer internal to your program, but I suppose calling POV-Ray gives you lots of functionality without having it to implement it yourself. Another goal of the project is to generate 2D prints from 3D models. Any idea how hard is this going to be? Basically it needs to identify features (holes, edges, etc), then project these features to an orthographic plane, alone with associated dimensions. That ought to be reasonably easy. If you think of each shape's surface as being the set of points satisfying an equation, then the edges of the intersection of those shapes would be the set of points satisfying a set of simultanious equations. (Quite possibly non-linear ones, depending on which kinds of shapes you allow.) The only really tricky part is if you want to represent all of these shapes as simple curves such as lines, ellipses and paraboliods. See, for example, http://mathworld.wolfram.com/SteinmetzSolid.html The curves of intersection of two cylinders of radii a and b, shown above, are given by the parametric equations x(t) = b cos t y(t) = b sin t z(t) = +/- Sqrt(a^2 - b^2 sin^2 t) (Gray 1997, p. 204). A curve like that is not the sort of thing you can easily represent in SVG, unless you turn it into a general spline. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 03/06/2011 05:02 PM, Albert Y. C. Lai wrote:
I propose that only {- -} is comment; that is, -- is an operator token
and not a marker of comments.
I'm curious to know why anybody thought that -- was a good comment
marker in the first place. (I'm curious because Haskell isn't the only
language to have made this strange choice.)
I once tried defining a ++ operator and then when I went to define a
matching -- operator...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell School of Expression (graphics)
On 28/05/2011 08:06 PM, michael rice wrote: /tmp/glib-0.11.22906/glib-0.11.2/Gtk2HsSetup.hs:190:70: Couldn't match expected type `[PackageDB]' with actual type `PackageDB' Expected type: PackageDBStack Actual type: PackageDB In the sixth argument of `registerPackage', namely `packageDb' In the expression: registerPackage verbosity installedPkgInfo pkg lbi inplace packageDb cabal: Error: some packages failed to install: cairo-0.11.1 failed during the configure step. The exception was: ExitFailure 1 There's some sort of glitch with Gtk2hs (on which SOE depends) that causes it to not build with GHC 7.x (?) unless you hand-edit some of the files (!) http://hackage.haskell.org/trac/gtk2hs/ticket/1203 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell School of Expression (graphics)
On 29/05/2011 02:52 PM, michael rice wrote: Is this worth chasing down? I loaded the Haskell Platform, which I assume has some graphics capability (Cairo?). Maybe my time would be better spent getting familiar with that? As far as I'm aware, the Haskell Platform doesn't come with any graphics-related packages, except low-level bindings to either X11 or Win32 (depending on which platform you're running on, obviously.) Cairo is part of the Gtk2hs collection of packages (i.e., the ones that aren't building right). The fix that makes Gtk2hs build isn't difficult, it's just tedious and error-prone. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell School of Expression (graphics)
On 29/05/2011 06:23 PM, Daniel Fischer wrote: On Sunday 29 May 2011 19:14:57, Andrew Coppin wrote: As far as I'm aware, the Haskell Platform doesn't come with any graphics-related packages I thought OpenGL was in the platform. Uh... yes, you might be right about that. However, AFAIK you still need something with which to create a rendering surface in the first place. (Not sure if HP includes GLUT...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On 18/05/2011 10:39 PM, Andrew Coppin wrote: On 18/05/2011 05:28 AM, Don Stewart wrote: I'm intrigued by the idea of Hackage docs that don't use Haddock. This is basically the reason I asked. Currently Cabal assumes that Haddock is the only tool of its kind. If somebody built a better Haddock, you wouldn't be able to use it. (Unless you named the executable haddock and made it accept the same command options.) Also, Haddock generates API reference documentation. It does not really support generating tutorials, introductions, HOWTOs, and all the other types of useful documentation that a project ought to have. Apparently there's already a ticket for this: http://hackage.haskell.org/trac/hackage/ticket/330 It seems part of the reason for inaction is that people would like a general way of saying how to generate different types of documentation. Myself, I would be content with a way to say put *these* files with documentation and tell the user where you've put them as a first step. We can worry about how to *generate* various types of documentation later... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient object identity (aka symbols as data)
On 26/05/2011 10:59 AM, Jacek Generowicz wrote: Any comments on the relative efficiency of the above as compared to A == B in the context of data Foo = A | B | C | D | ... lots more ... ? (I imagine that a Sufficiently Smart Compiler could reduce (==) :: Person Person to just integer comparison.) My understanding is that if you have a constructor with no fields, it gets allocated as a compile-time constant. In other words, C is just a pointer to a static data structure somewhere in the program binary, and (==) effectively becomes pointer equity. OTOH, I am not a GHC developer... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient object identity (aka symbols as data)
On 26/05/2011 07:56 PM, Andrew Coppin wrote: On 26/05/2011 10:59 AM, Jacek Generowicz wrote: Any comments on the relative efficiency of the above as compared to A == B in the context of data Foo = A | B | C | D | ... lots more ... ? (I imagine that a Sufficiently Smart Compiler could reduce (==) :: Person Person to just integer comparison.) My understanding is that if you have a constructor with no fields, it gets allocated as a compile-time constant. In other words, C is just a pointer to a static data structure somewhere in the program binary, and (==) effectively becomes pointer equity. OTOH, I am not a GHC developer... ...and what I *should* of course have written is go benchmark it. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 10:43 PM, Ketil Malde wrote: Andrew Coppinandrewcop...@btinternet.com writes: I'm trying to voice the opinion that there is such a thing as too many libraries. The article I linked to explains part of why this is the case, in a better way than I've been able to phrase it myself. I don't think so, the article seems to talk more about social problems among lisp users, which it - at least in part - ascribes to the technical prowess of the language. Actually, the author seems to be saying that Lisp is [relatively] unsuccessful because it's so powerful that is discourages cooperation. Personally I don't buy it; I'm sure there are *several* reasons why Lisp never became The Next Big Thing. (There's a dozen dialects of it, for starters...) But hey, I'm not really interested in Lisp. I'm interested in Haskell. What I took away from the article is that if you design a really powerful language, paradoxically this can make it cheaper to reimplement stuff rather than reuse it. You'd think a language with strong support for reuse would encourage reuse, but not necessary. As you point out, people not cooperating is a social rather than technical problem. It seems obvious once you say it out loud, but I hadn't really conciously realised that. Consequently, the language isn't the whole story. If you make the language really powerful, that reduces the cost of implementing things from scratch. On the other hand, if you can do things that reduce the cost of finding existing code that you could reuse, you swing the balance back in the other direction. We have Hackage (and now HP). I have no idea whether Lisp has anything comparable. The opinion that having too many libraries can be a problem, which some people don't seem to agree with. I don't see how the number of available libraries is a problem in itself, but it would be nice if hackage or some other resource provided more help in recommending which library to try first. We do have standardization efforts, committees bringing the language forward and an inclusive and collaborative community. I certainly don't think having a lot of libraries available is bad. Having lots of libraries available for /the same task/ is different. As some others have pointed out, it varies somewhat depending on what the task in question is. If Haskell still used the old lazy-list I/O approach and Hackage had 3 different monadic I/O libraries implemented on top of that, that would be really bad. Fortunately, once everybody realised that monadic I/O was the way to go, we ended up with one library which everybody uses. It has costs (e.g., you cannot redefine the Monad class to include, say, Data.Set), but it has the huge, huge benefit that nobody will ever utter the words I'd like to bolt HsLogger onto Yesod - oh wait, I can't, they use incompatible IO monads. On the other hand, there are lots of GUI libraries. Because they bind to different toolkits, or work on different combinations of platforms, or because they wrap low-level bindings with more functional interfaces, or whatever. We wouldn't want a massive *explosion* of identical GUI libraries, but I don't think the current set is excessive at all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 11:00 PM, Daniel Peebles wrote: I agree that from an end-user's perspective it isn't always a clear win, but I do think that having a bunch of libraries (even ones that do the same thing) an indicator of a healthy, active, and enthusiastic community. I won't argue with that. ;-) Sure, it's decentralized and people will often duplicate effort, but different variations on the same idea can also help explore the design space and will reveal to everyone interested what works and what doesn't. Yeah, as some others have said, it depends on the problem domain. For some things, it's really not clear what the correct abstractions are yet, and there's still a lot of design space to explore. (I might pick at random, say, Functional Reactive Programming. As best as I can tell, several people have ideas, but there's no clear best way of doing this yet. We're still experimenting.) For stuff like that, it's useful to have lots of people trying different stuff. But yeah, if you want to do X and you encounter 15 libraries that do X and can't find a clear consensus on what's best, I can understand why that might be frustrating. Moreover, there can be network effects involved. A while back somebody from Google wrote that everybody agrees that String is too slow for high-performance I/O, but each library that involves high-performance I/O tends to end up using a different text representation, which rather impedes compatibility between them. I don't think there's really a clear solution to that though, other than gently encouraging collaboration and scoping out of existing work before starting new work. But people generally hate working with other people's code, so I doubt that'll have much of an effect :) Yeah, I'm not going to present I have a solution. I merely wanted to point out that it's a problem which does exist. Some of the other folks in this thread seem to be coming up with useful ideas though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 08:39 PM, Felipe Almeida Lessa wrote: Regarding the Unicode problem, there is a standard solution today: use the text package. Yes, you may use other libraries, but text is the recommended one. Is that true? Last I heard, there was still some debate about the relative performance of the various libraries. (I don't recall hearing much argument about API though, so presumably everybody more or less agrees on that.) The problem is that no one coming to Hackage discovers that on Hackage itself. You have to dig the Internet to find some blog post telling you what to do. And hope that the blog post isn't old. ...I suppose what I just wrote basically confirms this. I remember seeing some traffic about text performance, but I wasn't paying enough attention at the time to remember the precise details. (Or perhaps it's just that this specific subject area isn't generally all that important to me.) So we really need a way of raking libraries in Hackage. We already have the Haskell Platform, which is really really nice, but the HP can't embrace everything. For everything outside HP, a ranking system is needed. Sounds like a good idea to me. My only minor worry is that when a once-popular library becomes superceeded by a superior competetor, the old library will still have a really good rating, and people might not find the new replacement. Then again, how often is that likely to happen? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
This is basically the reason I asked. Currently Cabal assumes that Haddock is the only tool of its kind. If somebody built a better Haddock, you wouldn't be able to use it. (Unless you named the executable haddock and made it accept the same command options.) Or maybe support for that tool would be integrated into Cabal and cabal and hackage. I believe the correct approach would be to make it easy to configure Cabal to use any tool that might be produced one day, rather than integrating support for each specific tool that actually exists. But even while such a tool is not yet available, it would be worth thinkng about hackage offering the possibility to display other docs than haddock- generated ones. Agreed. IF you do have better docs, host them somewhere, and put a link prominently in the .cabal file synopsis. That works, but it does mean that you can't read the documentation offline. Make it downloadable? Include the docs in the package (extra-source-files: thedocs.tar.gz) and mention it in the package descripiton for a (less than optimal) workaround. I thought extra-source-files: is only for Haskell source code? (It also requires you to have somewhere to host, which not everybody has. Haskellwiki, bitbucket, github, ... BitBucket only works for Mercurial, GitHub only works for Git. The Haskell wiki might be OK, and has the nice advantage that other people can improve it. (Do we think Hackage will ever get a wiki per package?) The other thing is, you can bet as soon as you put your package's documentation on the wiki and link it from the package description, the URL will change at some point, breaking the link. Sure, a centralised documentation-hosting would have advantages over sprinkling over all the free project-hosting services, but the situation is not unbearably dire as is. Granted. I'm just saying how it could be better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On 18/05/2011 11:25 PM, Ivan Lazar Miljenovic wrote: On 19 May 2011 08:09, Daniel Fischerdaniel.is.fisc...@googlemail.com wrote: On Wednesday 18 May 2011 23:39:47, Andrew Coppin wrote: (It also requires you to have somewhere to host, which not everybody has. Haskellwiki, bitbucket, github, ... Also if you have a project on code.haskell.org, then you also can have a website for it on projects.haskell.org Today is the first time I've seen these domain names mentioned. (They appear to be aliases to the same server that runs the rest of haskell.org...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Lisp Curse
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html Some of you might have seen this. Here's the short version: Lisp is so powerful that it discourages reuse. Why search for and reuse an existing implementation, when it's so trivially easy to reimplement exactly what you want yourself? The net result is a maze of incompatible libraries which each solve a different 80% of the same problem. To all the people who look at Hackage, see that there are 6 different libraries for processing Unicode text files, and claim that this is somehow a *good* thing, I offer the above essay as a counter-example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 07:56 PM, Gilberto Garcia wrote: I think what Andrew meant is that it's not a good idea to have big pile of different implementations of the same library, and all trying to solve the very same problem. I'm glad somebody understood what I was trying to get at. I'm not saying that we shouldn't ever have more than one library tackling the same problem. I'm just saying that when people say we have multiple libraries competing to solve this problem, and that's *great*... well, not necessarily, no. Obviously there's room for finding out what the best way to solve the problem is, but ultimately the ideal is to end up with one library that solves the problem well, which everybody can use. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 08:39 PM, Stephen Tetley wrote: Och Mr Coppin Lisp is a fine language, but all Lisp essays you'll find on the internet except Richard Gabriel's Worse is Better are absolute tosh. This wasn't an attempt to bash Lisp. This is about all those people who think having multiple libraries which only solve half the problem is somehow a good thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 08:58 PM, Don Stewart wrote: This is classic community trolling behavior, Andrew. And publicly calling somebody a troll isn't trolling behaviour? I'm going to answer the rest of this off-list. I'm sure nobody else wants to hear it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Lisp Curse
On 19/05/2011 09:34 PM, vagif.ve...@gmail.com wrote: Andrew, you are being non constructive. It seems I'm being misunderstood. Some people seem to hold the opinion that more libraries = better. I'm trying to voice the opinion that there is such a thing as too many libraries. The article I linked to explains part of why this is the case, in a better way than I've been able to phrase it myself. I'm not trying to say OMG, the way it is now completely sucks! I'm not trying to say you must do X right now! I'm just trying to put forward an opinion. The opinion that having too many libraries can be a problem, which some people don't seem to agree with. (Obviously it isn't *always* bad, I'm just saying that sometimes it can be.) That's all I was trying to say. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reverse Show instance
Cannot deduce (Show x) from context (Show (x, y)). Cannot deduce (Show y) from context (Show (x, y)). Um... seriously? From Prelude, we have Show x, Show y = Show (x, y) So clearly it works in the forward direction. But apparently not in the reverse direction. Is this a bug or a feature? (I.e., is there some obscure possibility I haven't thought of which means that doing the reverse inference would be incorrect?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reverse Show instance
On 19/05/2011 10:11 PM, Artyom Kazak wrote: And I can declare an instance for (x, y) which does NOT implies (Show x): instance Show (x, y) where show _ = I'm tuple! Hooray! Ah. So it's a feature. Fortunately I refactored the program where this came up, so it's no longer an issue. I just wanted to see whether or not it was a bug. PS. Wouldn't such an instance require FlexibleContexts or something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No fish, please
On 18/05/2011 05:28 AM, Don Stewart wrote: I'm intrigued by the idea of Hackage docs that don't use Haddock. This is basically the reason I asked. Currently Cabal assumes that Haddock is the only tool of its kind. If somebody built a better Haddock, you wouldn't be able to use it. (Unless you named the executable haddock and made it accept the same command options.) Also, Haddock generates API reference documentation. It does not really support generating tutorials, introductions, HOWTOs, and all the other types of useful documentation that a project ought to have. IF you do have better docs, host them somewhere, and put a link prominently in the .cabal file synopsis. That works, but it does mean that you can't read the documentation offline. (It also requires you to have somewhere to host, which not everybody has. Hackage provides hosting for the code itself, but you can only host documentation there if it's Haddock.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] = definition for list monad in ghc
On 16/05/2011 10:07 AM, Michael Vanier wrote: Usually in monad tutorials, the = operator for the list monad is defined as: m = k = concat (map k m) -- or concatMap k m but in the GHC sources it's defined as: m = k = foldr ((++) . k) [] m As far as I can tell, this definition is equivalent to the previous one (correct me if I'm wrong), so I was wondering why this definition was chosen instead of the other one. Does anybody know? Any time you see a more convoluted definition which ought to be equivilent to a simpler one, the answer is usually because this way makes some important compiler optimisation fire. It's even possible that the optimisation in question would fire anyway now, but way back when the code was written, the compiler wasn't as smart. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] No fish, please
Both Hackage and Cabal seem to assume as a matter of course that I want to use Haddock to generate all my documentation. Suppose I decide to violate this assumption. Then what? 1. Is there some way I can include my own HTML documentation in the package tarball and have Hackage/Cabal use it? 2. Is there a way to tell Hackage/Cabal to use some tool besides Haddock? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception for NaN
On 12/05/2011 06:14 PM, Grigory Sarnitskiy wrote: How do I make my program stop whenever it gets somewhere NaN as a result during a calculation? If there is no appropriate flag for ghc maybe there exist flags for C to use in optc. I don't want NaN to propagate, it is merely stupid, it should be terminated. There is an isNaN function somewhere. You could make a newtype over Double which performs an isNaN after every operations and throws an exception if necessary... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Those damned parentheses
On 10/05/2011 08:30 AM, Yitzchak Gale wrote: I think the clearest way to write it is: f = putStrLn . (++ - message received) . show . Main.id You're serious?? If I were to describe to someone in words what this function does, I would say something like: Apply Main.id, turn it into a string, tack a message onto the end, and print it. So why not write it that way in Haskell? Hmm, I suppose. OTOH, this breaks if you want to insert several items into a string. For example, f x y z = putStrLn (X = ++ show x ++ , Y = ++ show y ++ , Z = ++ show z) (Fortunately, here a simple call to ($) will fix you up nicely.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-class conditional behavior
On 08/05/2011 06:14 AM, Nicholas Tung wrote: Dear all, I'd like to write a function maybeShow :: a - Maybe String, which runs show if its argument is of class Show. This is surely an FAQ. Is the answer listed somewhere? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
On 07/05/2011 09:10 AM, Gregory Collins wrote: Linode. Can't recommend them highly enough. If Linode is really the cheapest that the Internet has to offer, I'm going to need to find a job that pays /significantly/ more money... (I'm also not sure whether being billed in USD is possibly a bad idea. Banks have a habit of charging you currency conversion fees for that. Then again, I haven't found many companies that list prices in GBP.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Server hosting
On 06/05/2011 07:16 PM, JP Moresmau wrote: I use Amazon EC2 Free Tier. You can install Yesod/Warp easily enough and it's fine for small traffic. My understanding is that EC2 is only free for 1 year, after which you pay full price. ($0.02/hour = $15/month if it's running full-time.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Gtk2hs on Windows
On 05/05/2011 09:50 PM, Andrew Coppin wrote: On 05/05/2011 01:32 AM, Albert Y. C. Lai wrote: Just 5 weeks ago, http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456 Did anyone see it? Right. So the problem might be GTK+ v3? Wrong. Apparently the bundle I downloaded contains GTK+ 2.20, which is fine. But the page above clarifies what the real problem is: HP 2011.2.0.1 doesn't work, apparently. (Doesn't say why.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Server hosting
OK, so strictly this is unrelated to Haskell as such. However, there's enough people doing webby stuff with Haskell that some of you must have wanted to run your code on a real, Internet-accessible web server. So does anybody have any suggestions on which companies offer the most favourable tools / pricing? I currently have a website, but it supports only CGI *scripts* (i.e., Perl or PHP). It does not support arbitrary CGI *binaries*, which is what I'd want for Haskell. In fact, I don't have control over the web server at all; I just put content on there. The same provider can offer me a virtual server, but at 3x the price I'm currently paying. I simply cannot afford that kind of money just for silly toy projects. What does everybody else use? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't build Gtk2hs on Windows
On 05/05/2011 01:32 AM, Albert Y. C. Lai wrote: Just 5 weeks ago, http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456 Did anyone see it? Right. So the problem might be GTK+ v3? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Advertisement: the Haskell Stack Overflow Q A site
One of the benefits of a site like SO as a forum is the ability to record and link to prior work, edit for technical errors, and easily search and categorize past answers. It is also less prone to noise, for those suffering from cafe overload. I would also recommend SO. My only experience of SO is that I asked a question once, and to this day it has still only been viewed a grand total of 6 times. (And I think that was just me looking to see if there were any replies yet.) OTOH, it wasn't Haskell-related. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't build Gtk2hs on Windows
Today I tried to install Gtk2hs. Big mistake! Last time I tried it, it was quite easy. Now that it uses Cabal, even on Windows you can compile this stuff from source fairly easily. It's just that you have to fiddle with environment variables to make it find stuff. However... 1. Since the move of haskell.org, the gtk2hs homepage has vanished off the face of the Earth. Is there any danger we might get this back some day? 2. http://hackage.haskell.org/trac/gtk2hs/ticket/1203 (In other words, every time you try to cabal install a GTK-related package, it fails during the register step, and you need to hand-edit Gtk2HsSetup.hs to fix the issue.) 3. http://hackage.haskell.org/trac/gtk2hs/ticket/1209 (In other words, certain GTK-related packages just plain fail to build due to undefined names or missing header files or...) In summary, it's just utterly broken. Which is very frustrating, given that not so long ago it was working really well. (I never did get Glade to work though... although it looks like that might be fixed now, if I could just get past all the other issues.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 28/04/2011 03:21 PM, Chris Smith wrote: On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote: There's also the fact that using in-repo branches means that all the tooling doesn't have to rely on any (fs-specific) conventions for finding branches. As someone who has admin'd a reasonably large Bazaar setup (where branch == directory similarly to Darcs) I can honestly say that this would be a HUGE boon. Just keep in mind that adding branches withing the repository is a massive increase in the conceptual complexity of the system, and it would IMO be very un-darcs-like to adopt something like that into the core mental model you need to use a darcs repository, only because of incidental conveniences Convention, rather than baking answers into tools, is the right way to solve organizational problems, and that's essentially what we're talking about here. And adding complexity every time someone has an awkward use case will lead (has led, in more systems than I can count) to an unusable result in the end. It seems half the people here think that having multiple branches per repo is a fantastic idea, while the other half think it's a stupid idea. Perhaps there is room for more than one revision control system based on change-sets in this world? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. It seems to me to be a considerable insight. Presumably David thought the same. I won't deny that there is a certain simplifying elegance to it. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, No, if on the same machine, the patches only appear once, it is just the index that duplicates some information (I think). In fact just as if it were a branch in another VCS. 1. Conceptually, you have the same information twice. 2. I have no idea how to make Darcs do the thing with hard links (is that even supported under Windows?) I just copy the whole folder using the normal OS file tools. Either way, you lose the ability to see how branches are related to each other, which might be useful in some cases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small Darcs anomoly
On 24/04/2011 06:33 PM, Jason Dagit wrote: On Sun, Apr 24, 2011 at 2:05 AM, Andrew Coppin andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote: So I was a little surprised to discover that... Darcs doesn't actually support doing this. Darcs is only really interested in the result of applying *all* changes in a repo. It seems daft to me that you would design a sophisticated system for splitting history into independent chunks, and then not let me manipulate them independently. This is because of a deliberate choice that was made by David Roundy. In darcs, you never have multiple branches within a single darcs repository directory tree. Yes, this seems clear. I'm just wondering whether or not it's the best design choice. To get the effect you want, you simply create two repositories. One having only the patches for ghc 6.6 and one having the patches of ghc 7.0 and then you pull just the patches you want from 7.0 into 6.6. There are options to 'darcs get' that help you select the right set of patches to help you create the two repositories. It does mean that you duplicate information. You have [nearly] the same set of patches stored twice, and you're not really storing the history of the relationship between two branches, only the history of the branch itself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http://trac.haskell.org/ not redering correctly
On 21/04/2011 02:36 AM, Conrad Parker wrote: I thought the purpose of filing a bug report was to get things fixed? The purpose of filing bug reports is to ensure that problems are not forgotten. It allows the community (people like you) to have a useful understanding of the problems that exist when choosing what tasks to put time and effort into fixing. *sigh* I guess that means the next step is to figure out if it's broken for the Linux builds as well, or just for Windows. (Can't test for Mac OS since I don't have access to the necessary hardware or software...) The first step would be to make a patch that works for you, and to attach it to the ticket. Wouldn't that require me to somehow get hold of whatever repo contains the script for generating the Windows installer? Then again if it's simply a matter of generating additional HTML text (as opposed to styling/rendering issues) then it should be straightforward to verify that the new content is added in the generated files without worrying about other platforms. I imagine the issue is something utterly trivial list a line of text missing from a file - which is why I'm so surprised that the problem has been reported multiple times and yet not fixed... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A small Darcs anomoly
I've discovered something interesting. Darcs stores history as a partially-ordered set of changes. This is a beautiful and elegant idea. In theory, this lets me apply any combination of changes, possibly generating file versions which have never actually existed before. (E.g., the new type checker from GHC 7.0 embedded in the GHC 6.6 codebase - not that I imagine it would compile, but in principle I can do it.) So I was a little surprised to discover that... Darcs doesn't actually support doing this. Darcs is only really interested in the result of applying *all* changes in a repo. If you want to apply some subset of changes, you need to make a seperate repo containing only the changes you want applied. It seems daft to me that you would design a sophisticated system for splitting history into independent chunks, and then not let me manipulate them independently. (If you think about it, the difference between, say, GHC 7.0 and GHC 6.6 is which set of changes are applied. Yet because Darcs doesn't support looking at it like this, you must have a completely seperate repo for each one...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 21/04/2011 11:16 PM, John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Ah, how silly of me. I should have known a question like this was highly likely to provoke a flamewar. I had assumed that the way Darcs was is *the definition of* what distributed version control is. So it was a bit of a shock to read about how Git works, and discovered that it does it totally wrong. So I want and read about Mercural and all the others, and discovered that they all do it wrong too. Given that the way Darcs works is so superior to the way everything else works, I was just puzzled as to why even GHC is trying to get rid of it. It seems the answer is some combination of performance issues (I've never seen any) and reliability issues (which again I've never come across). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why not Darcs?
I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http://trac.haskell.org/ not redering correctly
I notice that there's duplicate reports of the HTML documentation in the Haskell Platform having chunks missing Which ticket numbers are these? Trac allows one of them to be closed as a duplicate. Perhaps you can do that, or at least provide those details in email here. When I get a minute I'll log in, mark the duplicates, and add a note to the ticket confirming that the issue still exists. I thought the purpose of filing a bug report was to get things fixed? The purpose of filing bug reports is to ensure that problems are not forgotten. It allows the community (people like you) to have a useful understanding of the problems that exist when choosing what tasks to put time and effort into fixing. *sigh* I guess that means the next step is to figure out if it's broken for the Linux builds as well, or just for Windows. (Can't test for Mac OS since I don't have access to the necessary hardware or software...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http://trac.haskell.org/ not redering correctly
On 17/04/2011 11:29 AM, Erik de Castro Lopo wrote: Hi all, Trac pages aren't rendering correctly. It seems the HTTP server can't find the CSS files. See below. Cheers, Erik I'm glad it's not just me. Any danger of this being fixed someday? I notice that there's duplicate reports of the HTML documentation in the Haskell Platform having chunks missing, and yet both HP 2011.2.0.0 and HP 2011.2.0.1 still have this exact same problem. I thought the purpose of filing a bug report was to get things fixed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Questioning seq
A couple of questions: 1. Why is the existence of polymorphic seq bad? 2. Why would the existence of polymorphic rnf be worse? 3. How is pseq different from seq? That is all... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current heap size and other runtime statistics -- API for accessing in GHC?
On 11/04/2011 12:52 AM, Don Stewart wrote: I'd like a proper FFI binding for getting at Stats.c dynamically. So I can write programs that determine their own stats about the GC and so on. I have often wished that there was a much bigger API for interacting with the RTS. Currently, you can query how many capabilities there are, and you can request a (magor?) GC cycle. And that's *it*. One can imagine a far richer API, with the ability to do things like set and query RTS flags, query the GHC version number and RTS way, ask how much RAM is allocated to what, request a minor or magor GC, try to release RAM to the OS, pre-allocate RAM from the OS because you're about to use it, find out how many threads are running or how many sparks are queued, and so on. Of course, I doubt anyone is going to implement it anytime soon... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 30/03/2011 08:18 PM, Bas van Dijk wrote: It would also be great to have a package which combines the proper encoding/decoding of filepaths of the system-filepath package with the type-safety of the pathtype package: http://hackage.haskell.org/package/pathtype Oh sweet! I was just about to write a package exactly like this. Apparently I don't need to. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Three Google Summer of Code project proposals
*** Build multiple Cabal packages in parallel *** http://hackage.haskell.org/trac/summer-of-code/ticket/1594 Many developers have multi-core machines but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available. Isn't the Cabal build process strictly I/O-limited rather than CPU-limited? *** Simpler support for isolated/sandboxed Cabal builds *** http://hackage.haskell.org/trac/summer-of-code/ticket/1590 cabal-dev and capri allow developers to build packages in their own sandboxes, using a separate package database for each. This allows for isolated builds and prevents breakages due e.g. package upgrades. Merging cabal-dev into Cabal allows us to share lots of code and makes the feature more accessible to developers. This would be very useful. PS. I also love the way that performing cabal build causes it to claim that it's also registering the package, when in fact it isn't. Not sure why that spurious message is there... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader special Poetry and Fiction Edition
I think we should have a wiki page somewhere which explains what all the various Haskell-related terms mean. Terms like typing the knot and finally tagless. (Not to mention Oleg rating...) I have created such a page: http://www.haskell.org/haskellwiki/Terms Defining unlifted type without defining bottom probably isn't very helpful. (I'm sure there's already a wiki page for it though...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 17/03/2011 12:11 PM, Gábor Lehel wrote: Necroing this thread because I just noticed there's a (rather old!) bug report which covers much of the same ground and doesn't seem to have been mentioned by anyone: http://hackage.haskell.org/trac/ghc/ticket/1349 Right. So somebody else came up with an idea similar to mine, but since nobody could agree on anything more than a rough idea, nothing actually got done...(?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
Right. So somebody else came up with an idea similar to mine, but since nobody could agree on anything more than a rough idea, nothing actually got done...(?) Well, I also got the sense that it would be more than a little nontrivial to implement. Or at least, someone was talking about how it would be a good topic for writing a thesis about if someone managed to figure how to do it. I suspect that if someone were to actually put in the effort they would be afforded the privilege of getting to nail down the details. That's just completely baseless speculation, though. That sounds like a good description for just about every imaginable extension to Haskell that does something interesting! :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type trickery
The well-known ST monad uses an ingenious hack to make it impossible for distinct ST computations to interact with each other. Is there a way to do something similar so that I can create cursors that reference a (mutable) container, and then write a function that takes two cursor arguments which are statically guaranteed to refer to the same container? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type trickery
You could define a function: withContainer ∷ (∀ s. Container s → α) → α which creates a container, parameterizes it with an 's' that is only scoped over the continuation and applies the continuation to the created container. Hmm, yes. That will work, but I wonder if there's some way of doing this that doesn't limit the scope of the container to one single span of code... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader special Poetry and Fiction Edition
On 15/03/2011 11:35 PM, Brent Yorgey wrote: I am pleased to announce that the special Poetry and Fiction Edition of The Monad.Reader is now available [1]. Enjoy! I love exercise 8, write a complete computer game using this idea (!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subsets and supersets
The other day I saw the green field Haskell discussion on Reddit. Of course, I could give you a very long list (ha!) of things that I would change about Haskell. (This would probably begin with expunging Monad.fail with extreme prejudice...) But there's one particular feature which is non-trivial enough to be worth discussing here... Haskell has ADTs. Most of the time, these work great. As I've written in several other places (but possibly not here), OO languages tend to factor the problem the other way. That is, if I want a binary tree, an OO language makes me split the type and all of its operations into three parts (an abstract base class, a branch subclass, and a leaf subclass). Adding each new operation requires adding an abstract version of it to the abstract base class, and putting half of the implementation into each concrete subclass. Haskell is factored the other way. The definition of the type goes in one place. The definition of each operation over it goes in one place. More can be added at any time. In particular, the OO approach doesn't let you add new tree operations without altering the source code for the tree classes. The ADT version *does* let you add new operations - provided the tree structure is visible. This is not to say that the OO approach is wrong, of course. The important thing about a binary tree is that there are exactly two kinds of nodes - leaves and branches - and there will *always* be exactly two kinds. That's what makes it a binary tree! [OK, no it isn't, but bare with me.] If, instead of a binary tree, or an abstract syntax tree, or some other fixed, unchanging structure, we wanted to deal with, say, bank accounts... Well, there are a bazillion kinds of bank account. And more might be added at any time. Here an ADT is utterly the wrong thing to do. It would have a bazillion constructors, and all the processing for a particular bank account type would be split between dozens of seperate functions. By contrast, an OO language would put each account type and all its associated processing in the same place - the class definition. In summary, problems can be factored two ways. ADTs do it one way, classes do it the other way, and both can be appropriate. OO languages use classes, but, happily, Haskell has ADTs *and* classes! :-D And not classes in the same sense as OO classes; the way Haskell does it is actually better, IMHO. Anyway, coming back on-topic... ADTs are great, but sometimes they don't let me easily express exactly what I want. Specifically, sometimes I have one type which is really a subset of another type, or perhaps a superset of several times. You can build subsets using GADTs, after a fashion: data Foo data Bar data Foobar x where Foobar1 ... :: Foobar Foo Foobar2 ... :: Foobar Bar Foobar3 ... :: Foobar x Foobar4 ... :: Foobar Bar Foobar5 ... :: Foobar Foo Now any expression of type Foobar Foo is guaranteed to contain only Foobar1, Foobar3 or Foobar5, while any expression of type Foobar Bar is guaranteed to contain only Foobar2, Foobar3 or Foobar4. As the tangle of sets becomes more complicated, this approach becomes more difficult to apply. You can of course build supersets using an even more mundane Haskell construct. The canonical example is Either. If I want a field that holds a Foo *or* a Bar, I can trivially write Either Foo Bar. The trouble is, this entails an extra level of indirection. In order to access a Foo or a Bar, I now have to strip off the Left or Right constructor to get to it. To construct a value, I have to stick in the constructor. Sometimes this is just fine, even desirable. For example, I recently wrote a function who's type is spans :: (x - Bool) - [x] - [Either [x] [x]] Here the Left and Right constructors are actually /telling/ me something. They convey /information/. On the other hand, in the case of Either Foo Bar, the constructor tells me nothing. Consider: data Foo = Foo1 | Foo2 | Foo3 data Bar = Bar1 | Bar2 | Bar3 foobar :: Either Foo Bar - x foobar e = case e of Left Foo1 - ... Left Foo2 - ... Left Foo3 - ... Right Bar1 - ... Right Bar2 - ... Right Bar3 - ... There is, logically, no particular reason why we shouldn't simplify the function to just foobar Foo + Bar - x foobar fb = case fb of Foo1 - ... Foo2 - ... Foo3 - ... Bar1 - ... Bar2 - ... Bar3 - ... The set of possible constructors for Foo and for Bar are disjoint. There is no possibility of ambiguity here. The type system itself even /uses/ this fact to infer the type of literal constructor applications! And yet, you cannot write code such as the above. Not in Haskell, anyway. So what is the use case here? Well, consider for a moment the problem of parsing Haskell source code. Haskell contains both patters and expressions. Now actually, it turns out that a
Re: [Haskell-cafe] Type trickery
Hmm, yes. That will work, but I wonder if there's some way of doing this that doesn't limit the scope of the container to one single span of code... You can write helper functions which take containers as argument by parameterizing these helper functions over s: takesTwoContainers :: Container s1 - Container s2 - ... takesTwoContainers c1 c2 = ... -- c1 and c2 can be used here This function could be called like this: withContainer (\c1 - withContainer (\c2 - takesTwoContainers c1 c2)) -- c1 and c2 can be used here In this example, the scope of the containers is not limited to a single span of code. What you can't do is write functions such as foo :: Container x - (Cursor x, Cursor x) for example. Perhaps this property is just too tricky to check in the type system. It's quite possible to check it at run-time; I'd just prefer to check at compile-time, if it's not too difficult to implement. I thought of a further complication: What happens if you concatinate two containers? Then cursors to each of the original containers all become valid for the new, concatenated container. I suppose you could issue a new phantom type variable for the concatenated version, but the whole idea of mutable containers is to, you know, mutate them. Given the above, perhaps it's just not possible to check this kind of thing statically at all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader special Poetry and Fiction Edition
On 16/03/2011 03:05 PM, Brent Yorgey wrote: This kind of knot-tying approach is nice for static graphs. I think we should have a wiki page somewhere which explains what all the various Haskell-related terms mean. Terms like typing the knot and finally tagless. (Not to mention Oleg rating...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell IDE
On 07/03/2011 04:39 PM, Daniel Fischer wrote: That sounds nice, so I thought I'd try out leksah again. Unfortunately, the dependencies rule out GHC-7 Maybe someone could try relaxing the bounds and build it with GHC-7, and - if it works - upload a new version? (I could try if I get a go-ahead from Hamish or Jürgen) I couldn't get it to build either. So I just grabbed the Windows binary from the homepage and used that. Worked just fine... (Not sure that they have binaries for platforms that aren't Windows though. Can't remember off the top of my head.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2011.2
On 06/03/2011 11:46 AM, Andrew Coppin wrote: On 06/03/2011 01:22 AM, Don Stewart wrote: P.S. you can help by testing the installers, and reporting issues on the HP trac and mailing list. The candidate installers are here: http://code.galois.com/darcs/haskell-platform/download-website/ Is there some way to navigate to this page from the HP homepage? Seriously, if you want people to test it, having this fact more clearly visible seems like a good idea. (In particular, I have access to Windows systems I can test on, which is apparently rare around here, but until this email I had no idea that a release candidate was even available...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2011.2
On 08/03/2011 08:57 PM, Don Stewart wrote: We have plenty of testers on the haskell-platform@ list. If you're interested, you can join there to discuss results. By definition the test installers are not yet ready for haskell-cafe@ consumption. Oh, right. There's a mailing list? I wasn't aware of that. I'll go take a look... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform 2011.2
On 06/03/2011 01:22 AM, Don Stewart wrote: P.S. you can help by testing the installers, and reporting issues on the HP trac and mailing list. The candidate installers are here: http://code.galois.com/darcs/haskell-platform/download-website/ Is there some way to navigate to this page from the HP homepage? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell IDE
On 03/03/2011 07:12 AM, Eugene Kirpichov wrote: However, now I actually use vim - but that's because I'm scared of trying to install Leksah on Windows (maybe it isn't hard, I haven't tried) and because I'm only doing rather tiny things with Haskell at the moment. FWIW, last time I tried, installing Leksah on Windows consisted of downloading a compiled EXE file and double-clicking it. It was literally that complex. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
