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,
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
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
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.
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
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 :-).
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
[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
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
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
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
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)
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
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
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
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
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
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.
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
: [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
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?
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
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
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
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
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
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
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
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
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
44 matches
Mail list logo
