Re: [Haskell-cafe] Building production stable software in Haskell
On Sun, 2007-09-16 at 12:13 -0700, David Roundy wrote: On Sat, Sep 15, 2007 at 08:27:02AM +0100, Adrian Hey wrote: Perhaps what you really mean is, you long for a Data.Map.Strict that carries the offically blessed status of being shipped with ghc (reminds me of someone asking for a ghc approved SDL binding a while back :-). Yes, that would be what I mean. It seems Adrian's library is a replacement for Data.Map, only with higher performance and more features. What would the disadvantages be to replacing Data.Map with this implementation? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
David Roundy wrote: On Sat, Sep 15, 2007 at 08:27:02AM +0100, Adrian Hey wrote: Perhaps what you really mean is, you long for a Data.Map.Strict that carries the offically blessed status of being shipped with ghc (reminds me of someone asking for a ghc approved SDL binding a while back :-). Yes, that would be what I mean. Would you care to explain why you have this aversion to libs that aren't bundled with ghc? I am genuinely curious, because to me it seems strange to limit yourself this way, but you are clearly not alone in your aversion. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Hi Would you care to explain why you have this aversion to libs that aren't bundled with ghc? They are less stable and have less quality control. It is also an additional burden for a user to install the library to get the program working. cabal-install should fix the second. Some useful community feedback on hackage could fix the first. By removing most bundled libraries from GHC, we can get to the point where people _have_ to use non bundled libraries, then everyone will be on a more equal footing. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Ketil Malde wrote: It seems Adrian's library is a replacement for Data.Map, only with higher performance and more features. Well not quite for anyone using indexing or who needs O(1) size, but apart from that it should be a fully compatible replacement. At least that was my intention, though I must confess I've never tried substituting the clone for the current Data.Map in any code of my own (never used either, I always use the raw AVL lib). Are you speaking from experience, BTW? :-) What would the disadvantages be to replacing Data.Map with this implementation? Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
On 9/16/07, Ryan Ingram [EMAIL PROTECTED] wrote: Is there a way to make GHCi not print the result of an action but still make my variables get bound? This seems to be a common question (I myself asked it recently), so I've added an entry to the GHCi page on the wiki. Ideally, it would be nice if this were discoverable from within GHCi, but I'm not sure how this would best be done. Stuart What is the url for the wiki entry? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] C's fmod in Haskell
Maybe this is a stupid question, but I don't find something similar in Haskell. I find mod and rem, which work on integers. But I'm looking for a function similar to C's fmod. Of course I can write it myself, but I guess it must already exist under a different name? Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cross-compiling of GHC
Hi all: How to build a GHC which can run in a embed linux system ? I have toolchain for the targer system. Using which, I can compile on PC and run the program on the embed system. Is this means, if I change CC env-var to the toolchain compiler and compile GHC manually, I can get a program for the embed system ? I have read Building/Porting for GHC[1], that does not mention anything about how to build a GHC on a target machine using a cross-compiler like xxx-linux-gcc. *or* What do I need to do besides the stages that page mentioned ? Regards [1] http://hackage.haskell.org/trac/ghc/wiki/Building/Porting -- L.Guo 2007-09-17 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
On 9/17/07, Martin Lütke [EMAIL PROTECTED] wrote: What is the url for the wiki entry? There was already a page at http://haskell.org/haskellwiki/GHC/GHCi so I put it there, but I also took the liberty of creating some #REDIRECTs, so http://haskell.org/haskellwiki/ghci should work just as well. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C's fmod in Haskell
Peter Verswyvelen wrote: Maybe this is a stupid question, but I don't find something similar in Haskell. I find mod and rem, which work on integers. But I'm looking for a function similar to C's fmod. Of course I can write it myself, but I guess it must already exist under a different name? There's one in Data.Fixed called mod' Yes, that is an odd place for it :) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C's fmod in Haskell
Odd place it is, indeed! QUOTE: Data.Fixed... DESCRIPTION... This module defines a Fixed file:///D:/app/ghc-6.6.1/doc/html/libraries/base/Fixed.html type for fixed-precision arithmetic...*This module also contains generalisations of div, mod, and divmod to work with any Real instance.* Thanks a lot. I wouldn't have found that myself ;-) Jules Bean wrote: Peter Verswyvelen wrote: Maybe this is a stupid question, but I don't find something similar in Haskell. I find mod and rem, which work on integers. But I'm looking for a function similar to C's fmod. Of course I can write it myself, but I guess it must already exist under a different name? There's one in Data.Fixed called mod' Yes, that is an odd place for it :) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 10:05:36AM +0100, Neil Mitchell wrote: Would you care to explain why you have this aversion to libs that aren't bundled with ghc? They are less stable and have less quality control. It is also an additional burden for a user to install the library to get the program working. This is basically the issue. I've never used a Data.Map in any real code (that was written by me... Data.Map is used in xmonad, upon which I hack, but don't feel motivated to propose alternative requirements for installation), only in toy codes. And for that purpose, I didn't really want to go to the trouble of seeking out and researching various alternatives. For a trivial count the frequency of characters in a text file toy code, it hardly seems like a reasonable expectation that a beautiful implementation should require the installation of extra libraries. cabal-install should fix the second. Some useful community feedback on hackage could fix the first. By removing most bundled libraries from GHC, we can get to the point where people _have_ to use non bundled libraries, then everyone will be on a more equal footing. cabal-install may help, but what I'd really want is packaging in debian. That's my (biased, because I used debian) standard of a maintained, useful library. It's obviously a biased standard, but it isn't too hard for a package to get into debian, and if it *does* get into debian, it suggests someone cares about it. I don't like requiring obscure packages that perhaps have no code review, and perhaps have no users other than the author. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote: Ketil Malde wrote: What would the disadvantages be to replacing Data.Map with this implementation? Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. To me, it seems like a recipe for usefulness. It would allow data structures to be used in multiple libraries. Competing packages is fine and dandy for something like an XML parser or DBM interface, but I'd like data structures to be standard, so that other packages can use them in their interfaces without putting undue burden on their users (and without the users being forced to figure out how to convert back and forth between various different Data.Map.*). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 07:54:02AM -0700, David Roundy wrote: cabal-install may help, but what I'd really want is packaging in debian. That's my (biased, because I used debian) standard of a maintained, useful library. It's obviously a biased standard, but it isn't too hard for a package to get into debian, and if it *does* get into debian, it suggests someone cares about it. I don't like requiring obscure packages that perhaps have no code review, and perhaps have no users other than the author. I'm hoping that at some point we will have something similar to http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes where for questions like how do I import graphics and what should I use to write a letter particular packages are recommended, and reasons for choosing one over another are given. I've found this invaluable when doing LaTeX stuff. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cross-compiling of GHC
On Mon, Sep 17, 2007 at 07:32:53PM +0800, L.Guo wrote: I have toolchain for the targer system. Using which, I can compile on PC and run the program on the embed system. This isn't something that anyone's ever done with GHC, to the best of my knowledge. You'd probably have to get your hands dirty to make it work, but if you get stuck we can try to help you. By the way, GHC-specific questions are better asked on the [EMAIL PROTECTED] mailing list. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Records
On 9/16/07, Barney Hilken [EMAIL PROTECTED] wrote: Now that I have a version of ghc with type classes, I have had a go at implementing records based on the ideas I mentioned on this list a few months ago. The code of my first attempt is available at http:// homepage.ntlworld.com/b.hilken/files/Records.hs That's pretty interesting stuff, but it's hard to see how ti works without some examples. Would you want to include some in your comments? I do appreciate the thorough documentation otherwise, though. Justin p.s. replied via haskell-cafe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Neil Mitchell wrote: Would you care to explain why you have this aversion to libs that aren't bundled with ghc? They are less stable and have less quality control. Surely you jest? I see no evidence of this, rather the contrary in fact. Though I must admit the documentation situation for most of the ghc bundled libs does seems to have improved a lot recently, so I could imagine myself using some them if the need presented itself. I guess they must have been put to shame by some of the other libs out there :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 04:50:13PM +0100, Ian Lynagh wrote: On Mon, Sep 17, 2007 at 07:54:02AM -0700, David Roundy wrote: cabal-install may help, but what I'd really want is packaging in debian. That's my (biased, because I used debian) standard of a maintained, useful library. It's obviously a biased standard, but it isn't too hard for a package to get into debian, and if it *does* get into debian, it suggests someone cares about it. I don't like requiring obscure packages that perhaps have no code review, and perhaps have no users other than the author. I'm hoping that at some point we will have something similar to http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes where for questions like how do I import graphics and what should I use to write a letter particular packages are recommended, and reasons for choosing one over another are given. I've found this invaluable when doing LaTeX stuff. FWIW, I use the same policy with LaTeX packages as I do with Haskell libraries: if it's not in debian, then I don't want to use it, unless I want to hack on it (which isn't true of any LaTeX packages). Of course, it helps that almost any useful tex package is part of the tetex distribution, but I think this is a reasonable model to follow. I don't want to have to update my LaTeX code due to packages that change their API due to an upgrade, and I don't want to have to change my Haskell code due to a pachages that changes API on upgrade. I want good libraries, but more than that, I want stable libraries, and it seems to me that the library submission process for the standard haskell libraries reflects that. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
David Roundy wrote: On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote: Ketil Malde wrote: What would the disadvantages be to replacing Data.Map with this implementation? Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. To me, it seems like a recipe for usefulness. It would allow data structures to be used in multiple libraries. Competing packages is fine and dandy for something like an XML parser or DBM interface, but I'd like data structures to be standard I don't see fundamental difference between these. Why is so important that libs all use the same Maps but not important that they all use the same XML parser or DBM interface? If your gonna standardise you'd better be pretty sure about what it is that gets written in stone. I suspect that most Data.Map users are unaware that on performance grounds it would be hard to make a worse choice than the data structure currently used by Data.Map. It's the worst of all balanced tree implementations I've benchmarked. Furthermore any balanced tree implementation (including Data.Map and the AVL clone) will likely suck performance wise for non-trivial key types (even strings). But some will suck less than others. so that other packages can use them in their interfaces without putting undue burden on their users (and without the users being forced to figure out how to convert back and forth between various different Data.Map.*). I would consider it exceedingly poor design to produce a lib that mentioned (Data.)Map in it's API, precisely because that pretty much rules out the possibility of using any more efficient future map implementations without an API change. Ideally the way to deal with this is via standardised interfaces (using type classes with Haskell), not standardised implementations. Even this level of standardisation is not a trivial clear cut design exercise. e.g we currently have at least two competing class libs, Edison and the collections package. Which one should become standard? Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, 17 Sep 2007, Adrian Hey wrote: Ideally the way to deal with this is via standardised interfaces (using type classes with Haskell), not standardised implementations. Even this level of standardisation is not a trivial clear cut design exercise. e.g we currently have at least two competing class libs, Edison and the collections package. Which one should become standard? They shouldn't, at least not now. Knock up something lightweight that'll do for now for each of the modules that're going to be standard, worry about overarching frameworks later. Realistically we need a standardised name which we can expect to find an implementation under, with some performance guarantees even if they're the worst possible ones we can make. -- [EMAIL PROTECTED] 'In Ankh-Morpork even the shit have a street to itself... Truly this is a land of opportunity.' - Detritus, Men at Arms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Neil Mitchell wrote: Hi They are less stable and have less quality control. Surely you jest? I see no evidence of this, rather the contrary in fact. No, dead serious. The libraries have a library submission process. It does not follow that libraries that have not been submitted to this process are less stable and have less quality control. Nor does it follow that libraries that have been through this submission process are high quality, accurately documented, bug free and efficient (at least not ones I've looked at and sometimes even used). Also some libraries on hackage are 0.1 etc - even the author doesn't particularly think they are stable! There are plenty of libs bundled with ghc marked experimental or provisional (in fact pretty much all of them AFAICS) - even the author doesn't particularly think they are stable! :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
On Sat, 15 Sep 2007, Sam Hughes wrote: That's weird. Prelude (x,y) - return $ (repeat 1, repeat 2) You didn't tell, which Monad this shall be. Prelude Just x - return $ Just (repeat 1) [1,1,1,... Prelude (x,_) - return $ (repeat 1, repeat 2) [1,1,1,... Prelude Just (x,y) - return $ Just (repeat 1, repeat 2) Prelude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Andrew Coppin writes: Adrian Hey wrote: Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. Out of curiosity... what's so bad about stagnation? (Otherwise known as having a fixed structure that everybody can rely on...) Oh come on, you know the answer, do you like provocations? Shall I remind how many people are unhappy e.g., with the Haskell Numerical classes hierarchy?... Stagnation is stagnation. On a less serious tune: this what's so bad reasoning was the reason why some political regimes could not progress and had to be destroyed. Actually, it is not less serious... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
David Roundy [EMAIL PROTECTED] writes: Data.Map is a standardized interface, *not* a standardized implementation. I'm not saying it's a *good* standardized interface, but it's the only one we've got. Not so! There is another more venerable interface, namely Data.FiniteMap. That interface was deleted in favour of Data.Map, for no good reason that I am aware of. Indeed, I still have several pieces of software that continue to use the FiniteMap interface, but now have an extra home-grown indirection layer to connect to the current Data.Map implementation, just to enable the software to build. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 06:43:40PM +0100, Adrian Hey wrote: so that other packages can use them in their interfaces without putting undue burden on their users (and without the users being forced to figure out how to convert back and forth between various different Data.Map.*). I would consider it exceedingly poor design to produce a lib that mentioned (Data.)Map in it's API, precisely because that pretty much rules out the possibility of using any more efficient future map implementations without an API change. Ideally the way to deal with this is via standardised interfaces (using type classes with Haskell), not standardised implementations. Even this level of standardisation is not a trivial clear cut design exercise. e.g we currently have at least two competing class libs, Edison and the collections package. Which one should become standard? Data.Map is a standardized interface, *not* a standardized implementation. I'm not saying it's a *good* standardized interface, but it's the only one we've got. I would like to hope that the implementation could be improved without a change in interface. I agree that a type class interface would be better, and don't know what type class interface would be best. But until one of them is generally accepted, I'm not likely to learn to use either of them. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Swapping parameters and type classes
On 9/16/07, Mads Lindstrøm [EMAIL PROTECTED] wrote: Hi all If I have this type: data Foo a b = ... and this class class Bar (x :: * - *) where ... I can imagine two ways to make Foo an instance of Bar. Either I must apply the 'a' or the 'b' in (Foo a b). Otherwise it will not have the right kind. To apply the 'a' I can do: instance Bar (Foo a) where ... But what if I want to apply the 'b' ? How do I do that ? Greetings, Mads Lindstrøm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell (Redirecting to Haskell-Cafe) I think the easiest way to make it work is with a newtype wrapper around 'Foo a b' that swaps the arguments, like Brent mentioned. Without it you need some kind of type level lambda abstraction. Something like: instance Bar (\x - Foo x b) where ... But this is not valid Haskell. cheers, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I stop GHCi from calling show for IO actions?
On 9/17/07, Henning Thielemann [EMAIL PROTECTED] wrote: On Sat, 15 Sep 2007, Sam Hughes wrote: Prelude (x,y) - return $ (repeat 1, repeat 2) You didn't tell, which Monad this shall be. GHCi always runs in the IO monad. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-Marking finite/infinte lists?
On Sat, 15 Sep 2007, Joachim Breitner wrote: today while mowing the lawn, I thought how to statically prevent some problems with infinte lists. I was wondering if it is possible to somehow mark a list as one of finite/infinite/unknown and to mark list-processing functions as whether they can handle infinte lists. Thanks for asking this. I had the same question recently. :-) I think we should put the answers to the Wiki, Category:FAQ. (Is '2 times' frequent?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Observations from ListLike
Hi folks, I just announced ListLike[1] on [EMAIL PROTECTED] Rather than repeat that announcement here, I'd like to make a few observations that came out of the development of this program: * I wrote extensive QuickCheck cases for this and wrapped them in HUnit for better display and future extensibility. Two bugs in the GHC base libraries were discovered as a result (one has been fixed already in HEAD, one not) * Hugs programs that use cpphs can't use ByteString * It would be really nice if QuickCheck supported I/O and some version of HUnit's TestLabel to generate hierarchical names when failures occur. * It would also be much nicer if QuickCheck defined Arbitrary instances for Word8 and Char. On Hugs, QuickCheck also lacks an instance of Maybe, but GHC has it for some reason. * Testing functions like foldl in Hugs, where QuickCheck is supplying the list and the function, cause Hugs to crash with stack errors. Testing some functions over ByteStrings cause Hugs to crash complaining of being out of ForeignPtrs. I have yet to figure out how to fix either problem; raising the heap size doesn't help. * I had some cases in String.hs[2] where Hugs did not permit me to define the default functions within the class declaration. However, I could define the functions outside, with the exact same type signature as they'd have inside, and within the class declaration, just say something like words = myWords to refer to the external declaration. GHC worked fine both ways. It seems that Hugs has a number of issues with code like ListLike that uses some more advanced Haskell features, even though Hugs nominally supports them. If you look through my Mercurial changelogs, you'll see fix blah for hugs messages all over. Which is too bad, because Hugs seems more portable (especially to embedded devices) than GHC. [1] http://software.complete.org/listlike [2] http://software.complete.org/listlike/browser/src/Data/ListLike/String.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Building production stable software in Haskell
Philippa Cowderoy wrote: On Mon, 17 Sep 2007, Adrian Hey wrote: Ideally the way to deal with this is via standardised interfaces (using type classes with Haskell), not standardised implementations. Even this level of standardisation is not a trivial clear cut design exercise. e.g we currently have at least two competing class libs, Edison and the collections package. Which one should become standard? They shouldn't, at least not now. Knock up something lightweight that'll do for now for each of the modules that're going to be standard, worry about overarching frameworks later. Realistically we need a standardised name which we can expect to find an implementation under, with some performance guarantees even if they're the worst possible ones we can make. This is not OO programming. There can be looser coupling between type classes and the concrete data. I could imagine making each concrete Map implementation an instance of each of the offered class frameworks. So the Edison data types would be available under the Collections classes and vice versa. But since I have not used either, there may be some details that make this too annoying. Perhaps a class framework which cannot accept the foreign maps is not flexible enough; and a class framework which foreign maps can become instances of is a better choice? Anyway...time to sign off for today. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Adrian Hey wrote: Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. Out of curiosity... what's so bad about stagnation? (Otherwise known as having a fixed structure that everybody can rely on...) PS. If anybody *does* figure out how to build production stable software, in any language, please let the nice guys at VALVe know how to do it! :-} ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Hi What's bad about stagnation is that nobody will bother to produce anything better (at least not as a fully polished publicly available open source project), precisely because they have little chance of achieving a user base exceeding 1 (at least not if the attitude of David and Neil is typical of the community culture). I merely gave the reasons I suspected that David (and others) held their beliefs - I don't share them particularly. As a library author I have produced quite a few libraries (at least 5), and have received useful feedback from users which has helped me improve the libraries further. I think the largest barrier to having many libraries used in projects is the lack of a working cabal-install. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Building production stable software in Haskell
Philippa Cowderoy wrote: On Mon, 17 Sep 2007, Adrian Hey wrote: Ideally the way to deal with this is via standardised interfaces (using type classes with Haskell), not standardised implementations. Even this level of standardisation is not a trivial clear cut design exercise. e.g we currently have at least two competing class libs, Edison and the collections package. Which one should become standard? They shouldn't, at least not now. Knock up something lightweight that'll do for now for each of the modules that're going to be standard, worry about overarching frameworks later. Realistically we need a standardised name which we can expect to find an implementation under, with some performance guarantees even if they're the worst possible ones we can make. I am using the collections package on a regular basis, and I am quite satisfied. (I have no experience with Edison so I can't compare them.) The main advantage of a framework such as the collections package offers is that the code becomes a lot more flexible. First, it is easier to experiment with different implementations. In one application I wrote, you can switch from Data.Collections.StdMap (whose implementation is the familiar Data.Map) to e.g. Data.Collections.AvlMap by changing exactly /one/ line of code (of a total of about 1500 in 8 modules). No need to change any of the import declarations, no change in type signatures, nothing. Also, many functions, even whole classes, can be written more polymorphically and thus easier to use in situations other than what they were planned for; you can specify exactly the API that is needed and no more which strengthens static typing. The main disadvantage is that it can become quite hard to understand type errors, which often don't give me any clue what the /cause/ of the problem is. (This might be unavoidable, due to the level of polymorphism, I don't know.) In the end, I think something similar to the collections package should become 'standard' in the sense of getting distributed with the main Haskell implementations. This would encourage more people to try and use them, so we'd gather more experience and would be able to eliminate shortcomings sooner rather than later. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type-Marking finite/infinte lists?
Roberto Zunino wrote: apfelmus wrote: cons:: a - List e f a - List Nonempty f a But unfortunately, finiteness is a special property that the type system cannot guarantee. The above type signature for cons doesn't work since the following would type check bad :: a - List Nonempty Finite a bad x = let xs = cons x xs in xs In other words, Haskell's type system doesn't detect infinite recursion. I thought this was possible with GADTs (is it?): Interesting, it probably is. See below. data Z data S n data List a len where Nil :: List a Z Cons:: a - List a len - List a (S len) Then, bad (adapted from above) does not typecheck. Note that you're doing more than forcing your lists to be finite, you force them to be of a particular size. For instance, a list of type List a (S (S (S Z))) is guaranteed to have exactly 3 elements. That's why bad x = let xs = cons x xs in xs doesn't type check: the lhs has one more element than the rhs. As soon as you try to hide the finiteness proof (= count of elements in the list) away via existential quantification data ListFinite a where IsFinite :: List a len - ListFinite a the bad function reappears and type checks cons :: a - ListFinite a - ListFinite a cons x (IsFinite xs) = IsFinite (Cons x xs) bad :: a - ListFinite a bad x = let xs = cons x xs in xs But there is a major difference now: bad is not an infinite list, it's _|_. That's because cons is now strict in the second argument, i.e. it really does check whether the second argument matches the constructor IsFinite which means that there's a proof that xs is finite. That's good news, it seems to be that everything of type ListFinite is finite modulo _|_s. I don't have a proof, though. Of course, we can have a _|_ in every position, like cons 1 (cons 2 (IsFinite undefined)) which corresponds to 1 : 2 : _|_ Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
[EMAIL PROTECTED] wrote: Andrew Coppin writes: Out of curiosity... what's so bad about stagnation? (Otherwise known as having a fixed structure that everybody can rely on...) Oh come on, you know the answer, do you like provocations? Shall I remind how many people are unhappy e.g., with the Haskell Numerical classes hierarchy?... Stagnation is stagnation. I guess I'm too used to Java's class library, which seems to change every 12 hours or so. That's no fun at all! :-/ If something is broken, it should be fixed. If something isn't broken, I see no reason to change it. You might call that stagnation, but I view it as something else... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Hi They are less stable and have less quality control. Surely you jest? I see no evidence of this, rather the contrary in fact. No, dead serious. The libraries have a library submission process. Compare me changing my tagsoup library, to me changing my filepath library which comes bundled with GHC. I can do anything I want to the tagsoup library, but I need to wait at least 2 weeks and get general consensus before changing filepath. Also some libraries on hackage are 0.1 etc - even the author doesn't particularly think they are stable! Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Mon, Sep 17, 2007 at 07:38:00PM +0100, Malcolm Wallace wrote: David Roundy [EMAIL PROTECTED] writes: Data.Map is a standardized interface, *not* a standardized implementation. I'm not saying it's a *good* standardized interface, but it's the only one we've got. Not so! There is another more venerable interface, namely Data.FiniteMap. That interface was deleted in favour of Data.Map, for no good reason that I am aware of. Indeed, I still have several pieces of software that continue to use the FiniteMap interface, but now have an extra home-grown indirection layer to connect to the current Data.Map implementation, just to enable the software to build. True, it's not entirely stable, but I'd say that it's still more stable than the average external library. It's at least got a community-involved process for review of API changes. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Andrew Coppin wrote: If something is broken, it should be fixed. If something isn't broken, I see no reason to change it. You might call that stagnation, but I view it as something else... Nobody is talking about changing anything, at least not Data.Map. We're talking about why alternatives to Data.Map are apparently rejected out of hand for stupid, trivial and arbitrary reasons. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Andrew Coppin wrote: Adrian Hey wrote: Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. Out of curiosity... what's so bad about stagnation? (Otherwise known as having a fixed structure that everybody can rely on...) What's bad about stagnation is that nobody will bother to produce anything better (at least not as a fully polished publicly available open source project), precisely because they have little chance of achieving a user base exceeding 1 (at least not if the attitude of David and Neil is typical of the community culture). Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-Marking finite/infinte lists?
On 9/17/07, Roberto Zunino [EMAIL PROTECTED] wrote: I thought this was possible with GADTs (is it?): data Z data S n data List a len where Nil :: List a Z Cons:: a - List a len - List a (S len) Slightly related: The other day I was playing with exactly this GADT. See: http://hpaste.org/2707 My aim was to define a function like 'concat' in terms of 'foldr' but I was unable to do so. Can this be done? Also I was unable to define the function 'fromList :: [a] - ListN a n'. This makes sense of course because statically the size of the list is unknown. However maybe existential quantification can help but I'm not sure how. regards, Bas P.S. I also asked this on #haskell but I had to go away; Maybe I missed the answer... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records: Examples
{-# LANGUAGE TypeFamilies #-}
Hi Justin, thanks for your interest. Hope this helps!
module Examples where
import Records
To get started, you need to define your labels. They are just
singleton datatypes:
data FirstName = FirstName deriving (Show, Eq, Ord)
data Surname = Surname deriving (Show, Eq, Ord)
data Address = Address deriving (Show, Eq, Ord)
data PhoneNo = PhoneNo deriving (Show, Eq, Ord)
you can define as many as you like. Next you have to define the order
on fields. At
the moment you have to do this by hand, but I hope to get ghc to do
this automatically:
type instance NameCmp FirstName FirstName = NameEQ
type instance NameCmp FirstName Surname = NameLT
type instance NameCmp FirstName Address = NameLT
type instance NameCmp FirstName PhoneNo = NameLT
type instance NameCmp Surname FirstName = NameGT
type instance NameCmp Surname Surname = NameEQ
type instance NameCmp Surname Address = NameLT
type instance NameCmp Surname PhoneNo = NameLT
type instance NameCmp Address FirstName = NameGT
type instance NameCmp Address Surname = NameGT
type instance NameCmp Address Address = NameEQ
type instance NameCmp Address PhoneNo = NameLT
type instance NameCmp PhoneNo FirstName = NameGT
type instance NameCmp PhoneNo Surname = NameGT
type instance NameCmp PhoneNo Address = NameGT
type instance NameCmp PhoneNo PhoneNo = NameEQ
Now we are ready to play!
To define records, use (=:) and (+:)
barney = FirstName =: Barney +: Surname =: Hilken +:
Address =: Horwich +: PhoneNo =: 697223
You can use as many or as few of the fields as you like, and you can
write them in any order,
but trying to use a field twice in the same record will give you a
(rather incomprehensible)
type error.
justin = Surname =: Bailey +: FirstName =: Justin +: Address
=: Somewhere
To extract the value at a field use (.:)
myPhone = barney.:PhoneNo
To delete part of a record, use (-:)
noCallers = barney -: Address
To update existing fields in a record, use (|:)
barney' = barney |: Address =: ((barney .: Address) ++ , UK)
The power of the records system is that these five operators, =:
+: .: -: |: are Haskell
polymorphic functions. So you can define functions like
livesWith p q = p |: Address =: (q .: Address)
which returns p, but with its Address field changed to that of q.
Note that this function
works on any records p and q with Address fields, whatever other
fields they may have.
You can even define functions parametrised by field names:
labelZip n m = zipWith (\x y - n =: x +: m =: y)
then 'labelZip FirstName Surname' is a function which takes two lists
and returns a list of records:
names = labelZip FirstName Surname [Barney, Justin] [Hilken,
Bailey]
of course, labelZip isn't restricted to the four labels we defined
earlier, it works on anything.
The system is strongly typed, so record errors (such as missing or
duplicated fields) are caught
at compile time. There are type operators (:=:), (:+:), (:-:), (:.:)
corresponding to the record
operators, and classes `Contains`, `Disjoint`, `Subrecord` which
allow you to express conditions
on types. Unfortunately, the type system sometimes decides that a
function has a different type
from the one you expect, and won't accept the header you want to give
it. More experience with the
system is needed before we can say whether this is a problem.
Barney.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Competing packages for XML or DBM is really awful, unless they happen to be interface compatible. And there is a good way of switching imps at assembly time, such that lib code that consumes xml doesn't depend on which xml imp I have. Of course, I realize that a good interface for those is still an open topic. And bad standards really can be worse than no standard. So what it comes down to, is, how big a 'standard' library should a Haskell programmer expect? On 9/17/07, David Roundy [EMAIL PROTECTED] wrote: On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote: Ketil Malde wrote: What would the disadvantages be to replacing Data.Map with this implementation? Personally I don't really like the idea of Data.Map, Data.Map.AVL or any other lib becoming entrenched as official or de-facto standards. It seems like a recipe for stagnation to me. IMHO such libs just shouldn't be bundled with ghc (or any other compiler) for this reason. To me, it seems like a recipe for usefulness. It would allow data structures to be used in multiple libraries. Competing packages is fine and dandy for something like an XML parser or DBM interface, but I'd like data structures to be standard, so that other packages can use them in their interfaces without putting undue burden on their users (and without the users being forced to figure out how to convert back and forth between various different Data.Map.*). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] yi-gtk
who knows how to compile yi-gtk? i tried,but it told me mine miss gtk. 2007-09-18 clisper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sequencing Operations in a Monad
Paul Johnson-2 wrote: SevenThunders wrote: Unfortunately if I wrap my matrix references in the IO monad, then at best computations like S = A + B are themselves IO computations and thus whenever they are 'invoked' the computation ends up getting performed repeatedly contrary to my intentions. This sounds like a case for the infamous performUnsafeIO. The reason this is unsafe is that the compiler assumes that the IO computation it wraps has no visible side effects, so it doesn't matter when it is performed or how many times it gets performed. If your IO computation indeed has this nature then you are OK, but its up to you to make sure of this. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe In the end I went witth the performUnsafeIO 'solution'. It seems satisfactory but it is far from perfect. My matrices are stored in the C world as pointers on a stack. In Haskell land I only attempted to 'guarantee' that the contents of the referred matrices were referentially transparent. Thus, in theory, the stack order could change with function application order but the 'contents' of the matrices remain the same. For those routines that do alter current variables I force the output into the IO monad. There are two main problems with this approach. The first is that if a computation generates a new matrix by pushing it on to the stack, a problem might arise if one of it's dependent input matrices has not been evaluated yet and if it to requires a new matrix to be pushed on to the stack. Thus the output matrix could be 'pushed' prior to the dependent matrices. This sort of thing happens all the time with lazy evaluation. So my fix here is to write my low level routines with a lot of strictness annotations using $! and seq, wherever possible, as well as to force argument evaluation by sequencing them first in the IO monad. So far so good, but it is not perfect, one has to always keep this limitation in mind. The second problem is that it is necessary to maintain complete control over the C stack, allowing the library user to completely trash the stack if not careful, and utterly destroy referential transparency. Again one has to keep this in mind whenever stack manipulations or clearing variables off the stack. Still with these limitations, it looks like Haskell is going to make things reasonably nice. -- View this message in context: http://www.nabble.com/Sequencing-Operations-in-a-Monad-tf4446047.html#a12748654 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic thread management?
Couple of thoughts/observations: - Erlang has a vm, so that would avoid building a vm. On the downside, erlang is not pure: the message-passing and the io: commands imply the possibility of side-effects. Still, it could be good enough for a proof-of-concept? - implementation as a library function? Instead of building/modifying a vm to re-implement how map works, perhaps an easy way of doing this would be to create a new map function (dpmap? (=Dynamic parallel map), which chats to a scheduler process, which decides whether to split the map or not. Downside: constant overhead for all maps, even really small ones that would otherwise run really fast, and will ultimately be assigned only a single process anyway. (note: using erlang terminology here, where process means essentially thread). Of course, even modifying the vm to parallelize maps etc would have a constant overhead, but possibly the overhead could be much smaller if implemented directly in a vm? Possibly an approach could be: - impliment as a new dpmap library function - someone could optimize this in a vm later ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
Just out of curiosity, how could one do something like a factory, so
that by default a library uses, say, Data.Map, but by making a simple
assignment we can switch the library to use a different
implementation?
(This is alluded to above, but not explicitly stated. I guess it's
too easy, but someone has to ask the newbie questions :-D )
I guess we would need to have some sort of init function that
returns a state containing our various factories. The user could
update the factories with their own factories if they choose. The
state would need to be passed into each function call to the library
(!) ?
Or maybe one should store the state in a monad, and run everything
inside a monad?
Another newbie question, not entirely unrelated, but not entirely related ;-) :
- it seems that it is possible to run code inside multiple monads,
using transformers
- but it seems that there's no concept of nesting? ie, our code has
to explicitly know that it's going to be running inside exactly 2
monads (for example)
- or else, why does XmlToolbox, have 4 implementations for every
function, eg one using IO monad, one without IO monad, and two more
combinations involving a second monad?
From http://www.haskell.org/haskellwiki/HXT:
In HXT there are four types instanciated with these classes for pure
list arrows, list arrows with a state, list arrows with IO and list
arrows with a state and IO.
newtype LA a b = LA{ runLA :: (a - [b]) }
newtype SLA s a b = SLA { runSLA :: (s - a - (s, [b])) }
newtype IOLAa b = IOLA { runIOLA :: (a - IO [b]) }
newtype IOSLA s a b = IOSLA { runIOSLA :: (s - a - IO (s, [b])) }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On 9/18/07, Hugh Perkins [EMAIL PROTECTED] wrote: Just out of curiosity, how could one do something like a factory, so that by default a library uses, say, Data.Map, but by making a simple assignment we can switch the library to use a different implementation? (And of course, the 10 million dollar question: could one make GHC come with a standard factory state, with defaults, which we can update with our own factories in our code if we wish?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On 9/17/07, Hugh Perkins [EMAIL PROTECTED] wrote: Just out of curiosity, how could one do something like a factory, so that by default a library uses, say, Data.Map, but by making a simple assignment we can switch the library to use a different implementation? (This is alluded to above, but not explicitly stated. I guess it's too easy, but someone has to ask the newbie questions :-D ) I guess we would need to have some sort of init function that returns a state containing our various factories. The user could update the factories with their own factories if they choose. The state would need to be passed into each function call to the library (!) ? Or maybe one should store the state in a monad, and run everything inside a monad? Why would you want to do this in Haskell? Please explain in simple language for those of us who haven't been initiated into the secrets of design patterns. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt In fact, a sense of essence is, in essence, the essence of sense, in effect. -- Douglas Hofstadter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
