Re: [Haskell-cafe] Building production stable software in Haskell
On Tue, 2007-09-18 at 01:11 +0100, Neil Mitchell wrote: DBM's can differentiate themselves on external database support, Surely this is an opportunity to focus development on a single library with broader support? Currently, we have HSQL and HDBC supplying incompatible low-level interfaces, supporting a different set of back ends. No matter what I choose, I risk having to make a costly conversion later on. XML is not simple and does not interface to third party programs. I can think of at least 4 XML libraries, all of which are quite different. ...and at least some of them come with their own re-implementation of Data.Tree. I think competition and choice can be great, but I also think it is important to have a good default libraries to turn to for, well, production stable software. -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
On Mon, Sep 17, 2007 at 05:26:05PM +0100, Neil Mitchell wrote: 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. okay, but this fails in some cases. i wrote a package to obtain financial quotes. yahoo changed the webservice url on me. i rolled out a change within a day. in your model, people suffer a broken service for two weeks. clearly there is a time and a place for code review. there is also a time and a place for rapid response. Also some libraries on hackage are 0.1 etc - even the author doesn't particularly think they are stable! this is a sound practice and i applaud the authors for safely and soundly warning potential users of code immaturity. when my code has been in use for a year or so with no error reports, then i will say that it is stable and give it a 1.0 designation. until then, it is indeed in a testing mode. ___ 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 okay, but this fails in some cases. i wrote a package to obtain financial quotes. yahoo changed the webservice url on me. i rolled out a change within a day. in your model, people suffer a broken service for two weeks. I don't think Yahoo will change the syntax or semantics of filepaths anytime soon :-) If a new operating system (say Vista) had changed the semantics of filepaths then that would have been a fix, not a change, and provided it doesn't alter the behaviour for others then that would have been a bug fix that went in immediately. The code review is for interfaces - internal details are a bit more free, and clear bug fixes are not voted upon. 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
hughperkins: 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? Polymorphism, specifically, typeclasses, would be one option here. -- Don ___ 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 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] 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] 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] 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
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
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] 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
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
Re: [Haskell-cafe] Building production stable software in Haskell
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. -- 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: I long for a Data.Map.Strict, for instance, because it's so hard to use Data.Map without producing memory leaks... It's at times like this that I really wonder why on earth I bother working hard on libs for the benefit of the community. But I guess I'm not alone in that. You're surely aware of the existance of the Data.Map clone with knobs on that I wrote, since I can distinctly remember pointing it out to you in an earlier thread.. http://www.haskell.org/pipermail/haskell-cafe/2007-April/024730.html 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 :-). 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
I believe that rnf from the Control.Parallel.Strategies library shipped with GHC 6.6.1 is equivalent to deepSeq, as in: x `deepSeq` yis equivalent to rnf x `seq` y Isn't it? /g On 9/12/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: Thanks for all the info. It's really good news that code coverage is now part of the GHC compiler! Any more info on that deep seq? I can't find it in the libraries that come with GHC 6.6.1. It seems to be part of Control.Strategies.DeepSeq of HXT. This is a separate download? Intuitively, I would say deep seq forces strict evaluation of the complete graph of its first argument? Is this correct? Peter -Original Message- From: Don Stewart [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 10:11 PM To: Peter Verswyvelen Cc: Neil Mitchell; Haskell-Cafe Subject: Re: [Haskell-cafe] Building production stable software in Haskell bf3: Well, I actually meant more something like the imperative equivalences of code coverage tools and unit testing tools, because I've read rumors that in Haskell, unit testing is more difficult because lazy evaluation will cause the units that got tested to be evaluated We have full control over evaluation though, with bang patterns, seq and deep seq. Generally unit testing is generalised to property testing with QuickCheck, though. For code coverage, combined with testing, use HPC, the program coverage tool now in GHC head. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- The man who'd introduced them didn't much like either of them, though he acted as if he did, anxious as he was to preserve good relations at all times. One never knew, after all, now did one now did one now did one. ___ 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
Thanks for all the info. It's really good news that code coverage is now part of the GHC compiler! Any more info on that deep seq? I can't find it in the libraries that come with GHC 6.6.1. It seems to be part of Control.Strategies.DeepSeq of HXT. This is a separate download? Intuitively, I would say deep seq forces strict evaluation of the complete graph of its first argument? Is this correct? Peter -Original Message- From: Don Stewart [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 10:11 PM To: Peter Verswyvelen Cc: Neil Mitchell; Haskell-Cafe Subject: Re: [Haskell-cafe] Building production stable software in Haskell bf3: Well, I actually meant more something like the imperative equivalences of code coverage tools and unit testing tools, because I've read rumors that in Haskell, unit testing is more difficult because lazy evaluation will cause the units that got tested to be evaluated We have full control over evaluation though, with bang patterns, seq and deep seq. Generally unit testing is generalised to property testing with QuickCheck, though. For code coverage, combined with testing, use HPC, the program coverage tool now in GHC head. -- Don ___ 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
bf3: Thanks for all the info. It's really good news that code coverage is now part of the GHC compiler! Any more info on that deep seq? I can't find it in the libraries that come with GHC 6.6.1. It seems to be part of Control.Strategies.DeepSeq of HXT. This is a separate download? Intuitively, I would say deep seq forces strict evaluation of the complete graph of its first argument? Is this correct? Yep, that's it. Its rarely needed, but exists if you want it (its easy to define on your own too). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building production stable software in Haskell
The way I see it as a newcomer, Haskell shifts the typical imperical programming bugs like null pointers and buffer overruns towards space/time leaks, causing programs that either take exponentially long to complete, stack overflow, or fill up the swap file on disc because they consume gigabytes of memory. Other bugs I found are incomplete pattern matches at runtime, but I already got an email of how to fix this using an external tool, although it would be nice if this is part of the compiler/linker itself. How well and how can a Haskell program be tested to make sure it does not cause these space/time bugs? What tools are typically used? Thanks, Peter ___ 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 Peter, The way I see it as a newcomer, Haskell shifts the typical imperical programming bugs like null pointers and buffer overruns towards space/time leaks, causing programs that either take exponentially long to complete, stack overflow, or fill up the swap file on disc because they consume gigabytes of memory. Time bugs are quite rare - usually a simple profiling will fix them up, and they are exactly the same sorts of bugs that exist in an imperative programming language. Usually its a case of picking a better algorithm, or thinking clever thoughts. Space leaks are much more tricky - there are profiling tools, but I've never got enough experience using them to say anything more than that. Other bugs I found are incomplete pattern matches at runtime, but I already got an email of how to fix this using an external tool Did the email suggest using Catch? http://www-users.cs.york.ac.uk/~ndm/catch/ If you care enough about pattern matching, you can eliminate them all statically. 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
Well, I actually meant more something like the imperative equivalences of code coverage tools and unit testing tools, because I've read rumors that in Haskell, unit testing is more difficult because lazy evaluation will cause the units that got tested to be evaluated completely different depending on how they are used. In strict languages, this is not the case. Neil Mitchell wrote: Hi Peter, The way I see it as a newcomer, Haskell shifts the typical imperical programming bugs like null pointers and buffer overruns towards space/time leaks, causing programs that either take exponentially long to complete, stack overflow, or fill up the swap file on disc because they consume gigabytes of memory. Time bugs are quite rare - usually a simple profiling will fix them up, and they are exactly the same sorts of bugs that exist in an imperative programming language. Usually its a case of picking a better algorithm, or thinking clever thoughts. Space leaks are much more tricky - there are profiling tools, but I've never got enough experience using them to say anything more than that. Other bugs I found are incomplete pattern matches at runtime, but I already got an email of how to fix this using an external tool Did the email suggest using Catch? http://www-users.cs.york.ac.uk/~ndm/catch/ If you care enough about pattern matching, you can eliminate them all statically. 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
Hi
Well, I actually meant more something like the imperative equivalences
of code coverage tools and unit testing tools,
hpc and HUnit cover these two things pretty perfectly. hpc will be in
GHC 6.8, and its really cool :-)
because I've read
rumors that in Haskell, unit testing is more difficult because lazy
evaluation will cause the units that got tested to be evaluated
completely different depending on how they are used. In strict
languages, this is not the case.
That's a really weird statement, and one that goes completely opposite
to my view of things. Do you have sources for these rumours? In a pure
language, if you evaluate some code it will do exactly the same thing
every time - there is no different behaviour. If you test the code,
then run it again later, you'll get the same result. Compare that to
something like C where:
int breakRandomly = 0;
int return42()
{
breakRandomly = !breakRandomly;
return (breakRandomly ? 666 : 42);
}
In C you can test this, and it will work, then you can test it twice
with identical values, and it will break.
Lazy evaluation can hide bugs if you only demand some small portion of
the output, but if your property/test is constructed properly, you
shouldn't have any problem.
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
That's a really weird statement, and one that goes completely opposite to my view of things. Do you have sources for these rumours? In a pure language, if you evaluate some code it will do exactly the same thing every time - there is no different behaviour. If you test the code, Sorry, I did not express myself correctly I guess. I did not mean different behavior regarding the results that are computed (because that's the great thing about Haskell; this is called referentially transparent isn't it?), but I meant different time/space behavior. I'm not sure where I read this rumor, but if I recall correctly, it had to do with FRP (functional reactive programming), where it was stated that is was really difficult to make sure that no space/time leaks occurred when the user started combining functions in some way. But I might have understood it incorrectly; after all, I'm still in the learning process. Peter ___ 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 Tue, Sep 11, 2007 at 01:59:40PM +0200, Peter Verswyvelen wrote: That's a really weird statement, and one that goes completely opposite to my view of things. Do you have sources for these rumours? In a pure language, if you evaluate some code it will do exactly the same thing every time - there is no different behaviour. If you test the code, Sorry, I did not express myself correctly I guess. I did not mean different behavior regarding the results that are computed (because that's the great thing about Haskell; this is called referentially transparent isn't it?), but I meant different time/space behavior. I'm not sure where I read this rumor, but if I recall correctly, it had to do with FRP (functional reactive programming), where it was stated that is was really difficult to make sure that no space/time leaks occurred when the user started combining functions in some way. But I might have understood it incorrectly; after all, I'm still in the learning process. Yeah, that makes sense. Space leaks are tricky, and unit testing can only verify that under particular usage scenarios they don't occur, but in another case they might pop up. Generally, strict data types can help a lot in preventing space leaks, but can't always solve the problems. I long for a Data.Map.Strict, for instance, because it's so hard to use Data.Map without producing memory leaks... -- 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 9/11/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: How well and how can a Haskell program be tested to make sure it does not cause these space/time bugs? What tools are typically used? I've been fighting this myself. I had an especially nasty stack-overflow that took me weeks to track down. Of course, when I did, I used the tried-and-true divide-and-conquer approach. I found a case where my program consistently crashed, then I added output to see what was executed just before hand (luckily I was already in the IO monad). Finally, I wrote a test program that crashed the same way and was able to fix the bug. ANd, of course, it turned out to be my usage of foldr' - which is what I should have focused on first. Oh well. As for memory usage, I've been using the heap profiling tools in GHC quite a bit. They are scary at first, because they require you to compare postscript graphs, but once you spend some time with them they are actually very useful. This article describes an early version of the tools in GHC: http://citeseer.ist.psu.edu/runciman96heap.html And a web search using Heap profiling for space efficiency in functional programs gives some nice results. Justin ___ 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
bf3: The way I see it as a newcomer, Haskell shifts the typical imperical programming bugs like null pointers and buffer overruns towards space/time leaks, causing programs that either take exponentially long to complete, stack overflow, or fill up the swap file on disc because they consume gigabytes of memory. Other bugs I found are incomplete pattern matches at runtime, but I already got an email of how to fix this using an external tool, although it would be nice if this is part of the compiler/linker itself. How well and how can a Haskell program be tested to make sure it does not cause these space/time bugs? What tools are typically used? Stress testing is good for catching performance bugs. And space leaks are rare, and usually glaringly obvious. Incomplete pattern matches you can avoid with -Wall and Neil's tool 'Catch'. QuickCheck should also be employed liberally. -- Don ___ 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
bf3: Well, I actually meant more something like the imperative equivalences of code coverage tools and unit testing tools, because I've read rumors that in Haskell, unit testing is more difficult because lazy evaluation will cause the units that got tested to be evaluated We have full control over evaluation though, with bang patterns, seq and deep seq. Generally unit testing is generalised to property testing with QuickCheck, though. For code coverage, combined with testing, use HPC, the program coverage tool now in GHC head. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
