What *not* to use Haskell for

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Henning Thielemann

On Fri, 28 Nov 2008, Johan Tibell wrote:

> On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow <[hidden email]> wrote:
>
>> So we have two vector libraries, vector and uvector, which have a lot in
>> common - they are both single-dimension array types that support unboxed
>> instances and have list-like operations with fusion.  They ought to be
>> unified, really.
>
> Yes please! Could we please have a ByteString style interface with
> qualified imports instead of using ad-hoc name prefixes/suffixes as a
> namespacing mechanism if we're going to merge the two libraries?

StorableVector is organized this way.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Andrew Coppin
In reply to this post by Henning Thielemann
Henning Thielemann wrote:

>
> On Fri, 28 Nov 2008, Simon Marlow wrote:
>
>> Manuel M T Chakravarty wrote:
>>> Claus Reinke:
>>>> What do those folks working on parallel Haskell arrays think about the
>>>> sequential Haskell array baseline performance?
>>>
>>> You won't like the answer.  We are not happy with the existing array
>>> infrastructure and hence have our own.  Roman recently extracted
>>> some of it as a standalone package:
>>>
>>>   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector
>>>
>>> In the longer run, we would like to factor our library into
>>> DPH-specific code and general-purpose array library that you can use
>>> independent of DPH.
>>
>> So we have two vector libraries, vector and uvector, which have a lot
>> in common - they are both single-dimension array types that support
>> unboxed instances and have list-like operations with fusion.  They
>> ought to be unified, really.
>
> It's worse:
>    
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector
>  :-)

What *I* propose is that somebody [you see what I did there?] should sit
down, take stock of all the multitudes of array libraries, what features
they have, what obvious features they're missing, and think up a good
API from scratch. Once we figure out what the best way to arrange all
this stuff is, *then* we attack the problem of implementing it for real.

It seems lots of people have written really useful code, but we need to
take a step back and look at the big picture here before writing any
more of it.

IMHO, anyway...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Don Stewart-2
andrewcoppin:
> What *I* propose is that somebody [you see what I did there?] should sit
> down, take stock of all the multitudes of array libraries, what features
> they have, what obvious features they're missing, and think up a good
> API from scratch. Once we figure out what the best way to arrange all
> this stuff is, *then* we attack the problem of implementing it for real.
>
> It seems lots of people have written really useful code, but we need to
> take a step back and look at the big picture here before writing any
> more of it.

No.

My view would be to let the free market of developers decide what is
best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).

And this approach has yielded more code than ever before, more libraries
than ever before, and library authors are competing.

So let the market decide. We're a bazaar, not a cathedral.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Lennart Augustsson
But I don't want Perl, I want a well designed language and well
designed libraries.
I think it's find to let libraries proliferate, but at some point you
also need to step back and abstract.

  -- Lennart

On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart <[hidden email]> wrote:

> andrewcoppin:
>> What *I* propose is that somebody [you see what I did there?] should sit
>> down, take stock of all the multitudes of array libraries, what features
>> they have, what obvious features they're missing, and think up a good
>> API from scratch. Once we figure out what the best way to arrange all
>> this stuff is, *then* we attack the problem of implementing it for real.
>>
>> It seems lots of people have written really useful code, but we need to
>> take a step back and look at the big picture here before writing any
>> more of it.
>
> No.
>
> My view would be to let the free market of developers decide what is
> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).
>
> And this approach has yielded more code than ever before, more libraries
> than ever before, and library authors are competing.
>
> So let the market decide. We're a bazaar, not a cathedral.
>
> -- Don
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell!

Roman Leshchinskiy
In reply to this post by Simon Marlow-7
On 28/11/2008, at 20:04, Simon Marlow wrote:

> So we have two vector libraries, vector and uvector, which have a  
> lot in common - they are both single-dimension array types that  
> support unboxed instances and have list-like operations with  
> fusion.  They ought to be unified, really.

Yes. This shouldn't be too hard to do since both libraries are based  
on the internal DPH arrays. Although I have to admit that I never  
really looked at Don's code and have no idea how much he has changed.

But it's more than that. The basic idea behind vector is to provide a  
common framework for "normal" arrays, ByteString, StorableVector etc.  
It's not finished by a long shot but (unsurprisingly) I think it goes  
in the right direction. The proliferation of array-like libraries is  
counterproductive.

> The main difference between these libraries and Haskell's arrays is  
> the Ix class.  So perhaps Haskell's arrays should be reimplemented  
> on top of the low-level vector libraries?
> The Ix class is the root cause of the problems with optimising the  
> standard array libraries.

Yes, Haskell arrays should be based on a lower-level array library. I  
would also argue that they should be redesigned and given a more  
streamlined and efficient interface. The Ix class is not the only  
problem wrt efficiency. In particular, the H98 array library relies  
quite heavily on lists which makes implementing any kind of array  
fusion rather hard. In contrast to Ix, this is completely unnecessary,  
IMO.

Roman


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Claus Reinke
In reply to this post by Lennart Augustsson
> But I don't want Perl, I want a well designed language and well
> designed libraries.
> I think it's find to let libraries proliferate, but at some point you
> also need to step back and abstract.
>
>  -- Lennart

Especially so if the free marketeers claim there is something
fundamentally wrong with the standard libraries and language, as in
the case of arrays. When someone did that nice little survey of the
last bunch of array libraries (Bulat, I think? now in the wiki book),
I was hoping there would be a grand unification soon. Instead, it
seems that those who have worked most with Haskell arrays
recently have simply abandoned all of the standard array libraries.

Okay, why not, if there are good reasons. But can't you document
those reasons, for each of your alternative proposals, so that people
have some basis on which to choose (other than who has the loudest
market voice;-)? And would it be difficult for you all to agree on a
standard API, to make switching between the alternatives easy (if
it is indeed impossible to unify their advantages in a single library,
the reasons for which should also be documented somewhere)?
And what is wrong about Simon's suggestion, to use the standard
array lib APIs on top of your implementations?

Not that I see Haskell' coming soon, but I'd certainly not want it
to continue standardising a kind of array that appears to have no
backing among the Haskell array user/library author community. Nor
would I like something as central as arrays to remain outside the
standard, where it won't remain stable enough for Haskell
programmers to rely on in the long run.

bazaar, yes; mayhem, no.
Claus
 

> On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart <[hidden email]> wrote:
>> andrewcoppin:
>>> What *I* propose is that somebody [you see what I did there?] should sit
>>> down, take stock of all the multitudes of array libraries, what features
>>> they have, what obvious features they're missing, and think up a good
>>> API from scratch. Once we figure out what the best way to arrange all
>>> this stuff is, *then* we attack the problem of implementing it for real.
>>>
>>> It seems lots of people have written really useful code, but we need to
>>> take a step back and look at the big picture here before writing any
>>> more of it.
>>
>> No.
>>
>> My view would be to let the free market of developers decide what is
>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).
>>
>> And this approach has yielded more code than ever before, more libraries
>> than ever before, and library authors are competing.
>>
>> So let the market decide. We're a bazaar, not a cathedral.
>>
>> -- Don
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Roman Leshchinskiy
In reply to this post by Andrew Coppin

On 29/11/2008, at 08:43, Andrew Coppin wrote:

> What *I* propose is that somebody [you see what I did there?] should  
> sit down, take stock of all the multitudes of array libraries, what  
> features they have, what obvious features they're missing, and think  
> up a good API from scratch. Once we figure out what the best way to  
> arrange all this stuff is, *then* we attack the problem of  
> implementing it for real.

That is the idea behind vector. I don't know how good it is but it's  
the best I could come up with (or will be once it's finished). That  
said, I don't think there is such a thing as a perfect "array API".  
Different libraries serve different purposes.

Roman


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Don Stewart-2
In reply to this post by Claus Reinke
claus.reinke:

> >But I don't want Perl, I want a well designed language and well
> >designed libraries.
> >I think it's find to let libraries proliferate, but at some point you
> >also need to step back and abstract.
> >
> > -- Lennart
>
> Especially so if the free marketeers claim there is something
> fundamentally wrong with the standard libraries and language, as in
> the case of arrays. When someone did that nice little survey of the
> last bunch of array libraries (Bulat, I think? now in the wiki book),
> I was hoping there would be a grand unification soon. Instead, it
> seems that those who have worked most with Haskell arrays
> recently have simply abandoned all of the standard array libraries.


I don't think Bulat uploaded his libraries to hackage in the end. And if
it's not on hackage, then no one will use it, so it may as well not
exist.

 
> Okay, why not, if there are good reasons. But can't you document
> those reasons, for each of your alternative proposals, so that people
> have some basis on which to choose (other than who has the loudest
> market voice;-)? And would it be difficult for you all to agree on a
> standard API, to make switching between the alternatives easy (if
> it is indeed impossible to unify their advantages in a single library,
> the reasons for which should also be documented somewhere)?
> And what is wrong about Simon's suggestion, to use the standard
> array lib APIs on top of your implementations?


Nothing. This would be great. Who's volunteering to write the code?
The new 'list-like' fusible array libraries are still in alpha, anyway.


> Not that I see Haskell' coming soon, but I'd certainly not want it
> to continue standardising a kind of array that appears to have no
> backing among the Haskell array user/library author community. Nor
> would I like something as central as arrays to remain outside the
> standard, where it won't remain stable enough for Haskell
> programmers to rely on in the long run.


Hence the Haskell Platform. To provide the stability that people rely on
in the long run. Haskell' is not the process by which new libraries will
be standardised -- there's simply too many libraries being produced.

The platform let's us:

 * Take libraries out of the standardisation process.
 * Let developers develop in competition, and converge on agreed designs.
 * Let users decide what to use, rather than waste time standardising
   things when the developer community has already moved on.
 * And then publish a list of blessed code.

Since arrays are just another (non-obvious) data structure, there's a
huge design space:

 * flat and/or nested arrays?
 * strict or lazy or eager?
 * callable from C or Fortran?
 * mutable/immutable
 * polymorphic in what dimensions?
 * mmap-able?
 * read / write API, or list-like API?

We've not yet found the perfect implementation, but we're learning a lot.

And since it is not yet clear what the optimal solution looks like, I
say let the developers keep hacking for a while, until we get an idea of
what works.

And by all means, if someone thinks they know what the best API is, step
up and show us the implementation!

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Roman Leshchinskiy
In reply to this post by Claus Reinke
On 29/11/2008, at 10:47, Claus Reinke wrote:

>> But I don't want Perl, I want a well designed language and well
>> designed libraries.
>> I think it's find to let libraries proliferate, but at some point you
>> also need to step back and abstract.
>> -- Lennart
>
> Especially so if the free marketeers claim there is something  
> fundamentally wrong with the standard libraries and language, as in  
> the case of arrays. When someone did that nice little survey of the  
> last bunch of array libraries (Bulat, I think? now in the wiki  
> book), I was hoping there would be a grand unification soon.  
> Instead, it seems that those who have worked most with Haskell  
> arrays recently have simply abandoned all of the standard array  
> libraries.
> Okay, why not, if there are good reasons. But can't you document  
> those reasons, for each of your alternative proposals, so that  
> people have some basis on which to choose (other than who has the  
> loudest market voice;-)?

I think so far, it's always been the same two reasons: efficiency and  
ease of use. H98 arrays are inherently inefficient and IMO not very  
easy to use, at least not for the things that I'm doing.

> And would it be difficult for you all to agree on a standard API, to  
> make switching between the alternatives easy (if
> it is indeed impossible to unify their advantages in a single library,
> the reasons for which should also be documented somewhere)?

Yes, it is very difficult. A sensible API for a standard array library  
is something that needs more research. FWIW, I don't know of any other  
language that has what I'd like to see in Haskell. C++ probably comes  
closest but they have it easy - they don't do fusion.

> And what is wrong about Simon's suggestion, to use the standard  
> array lib APIs on top of your implementations?

Again, IMO H98 arrays are only suitable for a very restricted set of  
array algorithms.

Roman


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Claus Reinke
> Yes, it is very difficult. A sensible API for a standard array library  
> is something that needs more research. FWIW, I don't know of any other  
> language that has what I'd like to see in Haskell. C++ probably comes  
> closest but they have it easy - they don't do fusion.

I assume you've looked at SAC? http://www.sac-home.org/

Their main research and development focus was/has been on arrays
(fusion/layout/padding/tiling/slicing/data-parallelism/shape-invariance
(source algorithms parameterized over array dimensionality/shape)/
whole-array ops/list-like ops/lots of surface operations reducable to
a minimal set of core operations that need implementation/cache
behaviour/performance/performance/performance/..). When they
started out, I tried to make the point that I would have liked to have
their wonderful array ideas in our otherwise wonderful language,
but they preferred to follow their own way towards world
domination (*). Does that sound familiar?-)

Claus

(*) ok, they did have a good motive: they came out of a research
    group that had done non-sequential functional programming in
    the 1980s, with all the things we see today: great speedups,
    shame about the sequential baseline; creating parallel threads
    is easy, load balancing slightly harder, but pumping (creating
    thread hierarchies recursively, only to see them fold into a
    small result, for the process to begin again) is a waste, etc.;
    so they decided to start from a fast sequential baseline instead
    of full functional language, and designed their language around
    arrays instead of trying to add arrays to an existing language.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Belka
In reply to this post by Arnar Birgisson
If CPU would be lambda based, not imperative, that wouldn't count, I think. But pragmatically it counts. =)
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Andrew Coppin
In reply to this post by Lennart Augustsson
Lennart Augustsson wrote:
> But I don't want Perl, I want a well designed language and well
> designed libraries.
> I think it's find to let libraries proliferate, but at some point you
> also need to step back and abstract.
>  

I agree.

> On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart <[hidden email]> wrote:
>  
>> andrewcoppin:
>>    
>>> What *I* propose is that somebody [you see what I did there?] should sit
>>> down, take stock of all the multitudes of array libraries, what features
>>> they have, what obvious features they're missing, and think up a good
>>> API from scratch. Once we figure out what the best way to arrange all
>>> this stuff is, *then* we attack the problem of implementing it for real.
>>>
>>> It seems lots of people have written really useful code, but we need to
>>> take a step back and look at the big picture here before writing any
>>> more of it.
>>>      
>> No.
>>
>> My view would be to let the free market of developers decide what is
>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).
>>
>> And this approach has yielded more code than ever before, more libraries
>> than ever before, and library authors are competing.
>>
>> So let the market decide. We're a bazaar, not a cathedral.
>>    

I find this kind of attitude disturbing.

Are you seriously asserting that it's "bad" for people to stop and think
about their designs before building? That it's "bad" for people to get
together and coordinate their efforts? Would you really prefer each and
every developer to reinvent the wheel until we have 50,000 equivilent
but slightly different wheel implementations? Certainly you seem
obsessed with the notion that "more packages on Hackage == better". Well
in my book, quantity /= quality. (The latter being vastly more important
than the former - while admittedly far harder to measure objectively.) I
would far prefer to see one well-written library that solves the problem
properly than see 25 incompatible libraries that all solve small
fragments of the problem poorly. In the latter case, there will be no
"competition" between libraries; everybody will just give up and not use
*any* of them. You _can_ have too much choice!

I really hope I'm not the only person here who sees it this way...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Roman Leshchinskiy
In reply to this post by Claus Reinke
On 29/11/2008, at 11:49, Claus Reinke wrote:

>> Yes, it is very difficult. A sensible API for a standard array  
>> library  is something that needs more research. FWIW, I don't know  
>> of any other  language that has what I'd like to see in Haskell. C+
>> + probably comes  closest but they have it easy - they don't do  
>> fusion.
>
> I assume you've looked at SAC? http://www.sac-home.org/

Yes. They have it even easier - they don't have polymorphism, they  
don't have higher-order functions, they don't have boxing and laziness  
and in a sense, they don't even do general-purpose programming, just  
scientific algorithms. And they have no existing language to integrate  
their stuff with. This is not to imply that their work isn't  
interesting and valuable; IMO, it just doesn't really help us when it  
comes to designing a Haskell array library.

Roman


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Duncan Coutts
In reply to this post by Lennart Augustsson
On Fri, 2008-11-28 at 22:20 +0000, Lennart Augustsson wrote:
> But I don't want Perl, I want a well designed language and well
> designed libraries.
> I think it's find to let libraries proliferate, but at some point you
> also need to step back and abstract.

Yes, let the ideas simmer and when we can identify a consensus then we
can standardise something by including it into the Haskell platform.
There's obviously judgement involved to decide when it's right to
standardise. We can see all around us the results of standardising too
early or too late.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Brad Larsen
In reply to this post by Roman Leshchinskiy
On Fri, 28 Nov 2008 19:00:38 -0500, Roman Leshchinskiy <[hidden email]> wrote:

> On 29/11/2008, at 10:47, Claus Reinke wrote:
[...]
>> And would it be difficult for you all to agree on a standard API, to
>> make switching between the alternatives easy (if
>> it is indeed impossible to unify their advantages in a single library,
>> the reasons for which should also be documented somewhere)?
>
> Yes, it is very difficult. A sensible API for a standard array library
> is something that needs more research. FWIW, I don't know of any other
> language that has what I'd like to see in Haskell. C++ probably comes
> closest but they have it easy - they don't do fusion.
[...]

Would you elaborate on what you'd like to see in an array library?  And perhaps which C++ array library you are thinking of?  Your C++ comment caught my attention, and now I'm curious.  Surely you don't mean C-style arrays. :-D

Regards,
Brad Larsen



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Go Haskell! -> array libraries

John Lato-2
In reply to this post by Henning Thielemann
> From: Andrew Coppin <[hidden email]>
>
>>> My view would be to let the free market of developers decide what is
>>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).
>>>
>>> And this approach has yielded more code than ever before, more libraries
>>> than ever before, and library authors are competing.
>>>
>>> So let the market decide. We're a bazaar, not a cathedral.
>>>
>
> I find this kind of attitude disturbing.
>
> Are you seriously asserting that it's "bad" for people to stop and think
> about their designs before building? That it's "bad" for people to get
> together and coordinate their efforts? Would you really prefer each and
> every developer to reinvent the wheel until we have 50,000 equivilent
> but slightly different wheel implementations? Certainly you seem
> obsessed with the notion that "more packages on Hackage == better". Well
> in my book, quantity /= quality. (The latter being vastly more important
> than the former - while admittedly far harder to measure objectively.) I
> would far prefer to see one well-written library that solves the problem
> properly than see 25 incompatible libraries that all solve small
> fragments of the problem poorly. In the latter case, there will be no
> "competition" between libraries; everybody will just give up and not use
> *any* of them. You _can_ have too much choice!
>
> I really hope I'm not the only person here who sees it this way...
>

I would love to see a perfect, unified array library in Haskell.  I
think everyone would.  However, the problem Don, Roman, and others
have raised is that there is no single consensus on what that library
would look like, or how it would be implemented.  It might be
impossible for one library to fill the entire design space.  Don's
point is that, since this isn't yet a solved problem, having multiple
implementations available to see what works well (and what doesn't) is
a necessary step in finding a solution.

I also think this is a exactly why Hackage needs a way to indicate
that packages are deprecated/superceded by other packages.  There was
some talk about this recently, and IIRC even a submitted patch.  I
hope that gets adopted soon.

John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Andrew Coppin
John Lato wrote:
> I would love to see a perfect, unified array library in Haskell.  I
> think everyone would.  However, the problem Don, Roman, and others
> have raised is that there is no single consensus on what that library
> would look like, or how it would be implemented.  It might be
> impossible for one library to fill the entire design space.  Don's
> point is that, since this isn't yet a solved problem, having multiple
> implementations available to see what works well (and what doesn't) is
> a necessary step in finding a solution.
>  

Interesting. I thought this was more or less a solved problem, it's just
that nobody has yet had time to implement it all.

I mean, the Haskell '98 array libraries are OK, they're just rather
incomplete. We could do with the ability to have unboxed arrays of
arbitrary types. (Remember, this is the default position in Pascal / C /
C++ / most normal programming languages - although admittedly they don't
have ADTs.) It would be useful to have the option to dispence with Ix.
(And bounds checks, if you're sure you don't need them.) It would also
be useful to be able to "slice" arrays. And we have the new
parallel-array stuff coming now, but (AFAIK) it's fairly nontrivial to
switch between normal arrays and parallel ones. Plus there are lots and
lots of "obvious" and useful functions that aren't in the libraries.
(E.g., in-place map for mutable arrays.) It seems silly to reimplement
these every time you want to do something; they should be in the libraries.

I doubt there will ever be a "perfect" library for anything. But that
doesn't mean we can't take a few steps in the right direction. ;-)

> I also think this is a exactly why Hackage needs a way to indicate
> that packages are deprecated/superceded by other packages.  There was
> some talk about this recently, and IIRC even a submitted patch.  I
> hope that gets adopted soon.
>  

Agreed.

This goes beyond array libraries; do you have any idea how many "binary"
packages there are?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Austin Seipp
In reply to this post by Andrew Coppin
Excerpts from Andrew Coppin's message of Sat Nov 29 03:37:58 -0600 2008:
> Are you seriously asserting that it's "bad" for people to stop and think
> about their designs before building?

To be fair, I don't think you're in a position to say whether the
authors of these libraries took careful consideration in their design
or not; unless, of course, you wrote one of them and *didn't* think
about the design?

Austin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Don Stewart-2
In reply to this post by Andrew Coppin
andrewcoppin:

> >>
> >>My view would be to let the free market of developers decide what is
> >>best. No bottlenecks -- there's too many Haskell libraries already (~1000
> >>now).
> >>
> >>And this approach has yielded more code than ever before, more libraries
> >>than ever before, and library authors are competing.
> >>
> >>So let the market decide. We're a bazaar, not a cathedral.
> >>    
>
> I find this kind of attitude disturbing.
>
> Are you seriously asserting that it's "bad" for people to stop and think
> about their designs before building? That it's "bad" for people to get
> together and coordinate their efforts? Would you really prefer each and
> every developer to reinvent the wheel until we have 50,000 equivilent

Strawman, Andrew, and rather silly too.

I'm aggressively in favour of reuse. That's why I advocate everyone use
and contribute to Hackage, so that they can reuse other's work, and they
can collaborate on existing code.

The current approach of /people who do things/ is working very well.
They're designing and implementing new ideas in the language, leading to
interesting collaborations, and new designs, and more code, that does
more things, than ever before.

And I'm in favour of that.

I never thought I'd say the day when people complained about there being
too many libraries for Haskell. Mwhahaha!

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Go Haskell! -> array libraries

Andrew Coppin
In reply to this post by Austin Seipp
Austin Seipp wrote:

> Excerpts from Andrew Coppin's message of Sat Nov 29 03:37:58 -0600 2008:
>  
>> Are you seriously asserting that it's "bad" for people to stop and think
>> about their designs before building?
>>    
>
> To be fair, I don't think you're in a position to say whether the
> authors of these libraries took careful consideration in their design
> or not; unless, of course, you wrote one of them and *didn't* think
> about the design?
>  

I said "I think we should take a step back and work out a plan" and Don
said "no, I think we should just keep blindly hacking away instead". So
I said that seems like a very bad idea to me...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345