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

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

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

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

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

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

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

On Mon, Sep 17, 2007 at 07:38:00PM +0100, Malcolm Wallace wrote:

David Roundy 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

Hi

Competing packages for XML or DBM is really awful, unless they happen to be interface compatible.

Imagine two XML libraries which share the same interface. That implies that they have exactly the same design criteria, take the same view of XML files and are pretty much the same in every user visible way. The only way they can differentiate each other is in performance, so either: 1) one is ridiculously slow, the other is fast. end result, only one XML library 2) they are the same speed. the user has no benefit, but the development costs double DBM's can differentiate themselves on external database support, Data.Map's can have different amortised costs and are quite simple in terms of interface. 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. An application that suits tagsoup will not suit HaXml, and vice versa. Thanks Neil

On 9/18/07, Hugh Perkins 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?)

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

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

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

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

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

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

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

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

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

On 18-sep-2007, at 14:10, Simon Marlow wrote:

Adrian Hey 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

Neil Mitchell wrote: 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. -- /\ / | arthurvl@cs.uu.nl | 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

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

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:dons@galois.com] 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

I believe that rnf from the Control.Parallel.Strategies library shipped with GHC 6.6.1 is equivalent to deepSeq, as in: x `deepSeq` y is equivalent to rnf x `seq` y Isn't it? /g On 9/12/07, Peter Verswyvelen 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:dons@galois.com] 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.