[Haskell-cafe] Re: Building production stable software in Haskell
Ketil Malde wrote: 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. Yes, a common low-level interface is highly recommended. This does not only hold for DBMs, but also for XML, GUIs, vector graphics etc. The (imaginary, I'm a DB illiterate) picture is this: HDB -+ +--- Borland | | LambdaBase --+--- Generic Low-level DB --- +--- Oracle | | hasqel --+ +--- MySQL | | ... ... A common low-level interface factors the m - n relation into a m - 1 and a 1 - n relation. The story doesn't end here, since there can be additional low-level functionality that only some DB backends can offer but that some high-level interfaces require. But that's just a matter of putting another type class on top of the minimal low-level type class. Of course, designing a low-level interface that is neither too powerful (not all back ends offer the functionality) nor too general (being almost trivial) and still simple enough is *hard*, especially since you can think about it for weeks without touching a computer. Regards, apfelmus ___ 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
Adrian Hey wrote: 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). Adrian's right - the set of libraries that are shipped with GHC is essentially random. A bit of history: Originally we shipped pretty much all freely-available non-trivial Haskell libraries with GHC. At some point (about 5 years ago or so) the number of Haskell libraries started to grow beyond what we could reasonably ship with GHC, and some of them were providing duplicate functionality, so we stopped adding to the set. We made a few small exceptions (e.g. filepath) for things that we felt really should be in the default GHC install, but to a large extent the set of libraries that are shipped with GHC has remained constant over the last 3 major releases. In 6.6, we made a nomenclature change: we divided the packages shipped with GHC into two: those that are required to bootstrap GHC (the boot libraries, until recently called the core libraries), and the others that we just include with a defualt binary install (the extra libraries). On some OSs, e.g. Debian, Ubuntu, Gentoo, you don't even get the extra libraries by default. This was intended to be a stepping stone to decoupling GHC from these libraries entirely, which is possible now that we have Cabal and Hackage. What I'm getting around to is that being shipped with GHC is not a category that has any particular meaning right now. I think it's time the community started to look at what libraries we have in Hackage, and identify a subset that we should consider standard in some sense - that is, those to which the library submission process applies, at the least. If there were such a set, we could easily make GHC's extra libraries equal to it. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Building production stable software in Haskell
On 18-sep-2007, at 14:10, Simon Marlow wrote: Adrian Hey wrote: 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). Adrian's right - the set of libraries that are shipped with GHC is essentially random. A bit of history: Originally we shipped pretty much all freely-available non-trivial Haskell libraries with GHC. At some point (about 5 years ago or so) the number of Haskell libraries started to grow beyond what we could reasonably ship with GHC, and some of them were providing duplicate functionality, so we stopped adding to the set. We made a few small exceptions (e.g. filepath) for things that we felt really should be in the default GHC install, but to a large extent the set of libraries that are shipped with GHC has remained constant over the last 3 major releases. In 6.6, we made a nomenclature change: we divided the packages shipped with GHC into two: those that are required to bootstrap GHC (the boot libraries, until recently called the core libraries), and the others that we just include with a defualt binary install (the extra libraries). On some OSs, e.g. Debian, Ubuntu, Gentoo, you don't even get the extra libraries by default. This was intended to be a stepping stone to decoupling GHC from these libraries entirely, which is possible now that we have Cabal and Hackage. What I'm getting around to is that being shipped with GHC is not a category that has any particular meaning right now. I think it's time the community started to look at what libraries we have in Hackage, and identify a subset that we should consider standard in some sense - that is, those to which the library submission process applies, at the least. If there were such a set, we could easily make GHC's extra libraries equal to it. Ofcourse, now we hit the situation that Eclipse is in as well: everything worthwhile should be downloaded next to the base functionality. This has lead to many slightly differing distributions of Eclipse. The same problem occurs with Linux distributions... I personally always liked Python's 'batteries included' approach. Python comes with enough libs standard to be genuinely useful. This, I think, is a good model from a marketing point of view. With regards, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ 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
[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
