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.
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 filepath
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 chang
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, su
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 abov
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 mill
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 someo
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 us
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
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)
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
[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 t
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 bundle
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! T
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 i
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
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 w
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
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
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 pro
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 com
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, 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."
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 mos
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
> pack
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-fact
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 p
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
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 com
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 :-).
Y
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 "g
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
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.
Yo
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"
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?
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
&g
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
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
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 d
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
> > ever
> 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 d
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 mo
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 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
> th
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 gigaby
45 matches
Mail list logo
