One to add to your list, string edit distance - as its hard, and useful.
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
karczma [EMAIL PROTECTED] writes:
I think the Haskell community has just been a bit slower in understanding
the importance of strictness :)
OK, I admit that I will never understand these complaints about the
inefficiency of non-strict computations, since what I *require* in most
of my
Jerzy Karczmarczuk writes (in the Haskell cafe):
OK, I admit that I will never understand these complaints about the
inefficiency of non-strict computations, since what I *require* in most
of my work is laziness. Had I needed strictness for the sake of efficiency,
I would use a different language
n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote:
karczma [EMAIL PROTECTED] writes:
I think the Haskell community has just been a bit slower in understanding
the importance of strictness :)
OK, I admit that I will never understand these complaints about the
On Mon, 11 Oct 2004 14:16:36 -0700, John Meacham [EMAIL PROTECTED] wrote:
n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote:
So is it fair to compare the default lazy Haskell solution with all
the eager solutions out there that laboriously do all this unnecessary
work?
Malcolm Wallace wrote:
For instance, the shootout often requires that a task be carried out N
times, to make the timings large enough to measure. In all the naive
Haskell implementations of these tasks, Haskell wins by a mile. Why?
Because the language quite reasonably says that if you
Ketil Malde ([EMAIL PROTECTED]) wrote:
As somebody just said, you get to chose between speed and
simplicity/clarity of code. I would like both.
Me too.
Simplicity/calrity of code is, imho, one of the strong point in using Haskell.
Couldn't readFile et al. provide the standard interface,
Ketil Malde writes:
Couldn't readFile et al. provide the standard interface,
but use hGetBuf tricks (e.g. from your 'wc' entry) behind
the curtains?
No amount of hGetBuf'ing will speed the program up if the
problem is the algorithm. I/O comes _sequentially_, and
every program that doesn't
Andrew Butterfield [EMAIL PROTECTED] writes:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry
language)
No - Clean is pure and lazy like Haskell,
But it uses explicit strictness annotations a lot, and
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote:
Andrew Butterfield [EMAIL PROTECTED] writes:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry
language)
No - Clean is pure and lazy like Haskell,
But it uses
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote:
Andrew Butterfield [EMAIL PROTECTED] writes:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry
language)
No - Clean is pure and lazy like Haskell,
But it uses
On 08-Oct-2004, Andre Pang [EMAIL PROTECTED] wrote:
I believe that Marcin wishes to prove the same point that I want to:
namely, Clean encourages use of strictness by making it easier to use
(via language annotations). At the risk of sounding ignorant and
arrogant, I think the Haskell
I feel a bit guilty for my ugly wc implementation. At the moment of
writing the first version I was thinking only about efficiency, not
about elegance.
[..]
We have already created on this list a version which is
fast and quite elegant at the same time, and I feel this one is better
for the
Peter Simons [EMAIL PROTECTED] writes:
Keith Wansbrough writes:
Count me as a vote for the better-but-slightly-slower wc.
How about the attached program? On my machine it faster than
Tomasz's version, and I think it's still a fairly clean
source code
I guess it's possible to submit three
Well, the sootout itself is using GHC, as it lists both
language and implementation. There is no entry for NHC
or Hugs... So I would say if the GHC specific code is
neat and fast put it in... If people hant to see a NHC
then there should be a separate implentation of haskell
(for example I can
Also, its nice to see GHC ahead of Java now in the standard
results... Would be nice to beat OCaml Clean though ...
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
looking at ghc's scores... this would seem to be the next candidate for
a rework:
-- $Id: reversefile.ghc.html,v 1.6 2004/10/03 00:44:58 bfulgham Exp $
-- http://www.bagley.org/~doug/shootout/
-- from Julian Assange
main = interact $ unlines . reverse . lines
Compare this with the gcc
MR K P SCHUPKE [EMAIL PROTECTED] writes:
Well, the sootout itself is using GHC, as it lists both
language and implementation. There is no entry for NHC
or Hugs...
Both nhc98 and Hugs have been added in the last few days.
Regards,
Malcolm
___
Andre Pang writes (in the Haskell cafe):
The executive summary of my thoughts is that it seems to be
entirely possible to optimise Haskell to be competitive with
other, more performance-focused languages, but it's hard...
and from his blog:
if you need speed, you can get it in Clean much more
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry language)
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
At 03:08 PM 07/10/2004 +0100, MR K P SCHUPKE wrote:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry language)
No - Clean is pure and lazy like Haskell,
- the key difference is that it uses
uniqueness types
Andre,
I very much enjoyed reading your blog entry. I would like to make a few
comments.
First of all I heartly agree with what you call the main problem. I
quote: The main problem I see with all this is that its just too hard
for an average Haskell programmer to get good performance out of
MR K P SCHUPKE wrote:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry language)
Wrong on both accounts.
See http://www.cs.ru.nl/~clean/About_Clean/about_clean.html and
On Thursday 07 Oct 2004 3:29 pm, Andrew Butterfield wrote:
At 03:08 PM 07/10/2004 +0100, MR K P SCHUPKE wrote:
I though clean was always strict, and that was the major difference
between clean and haskell (that and the fact clean is a proprietry
language)
No - Clean is pure and lazy like
what about, quote:
N.B. CleanLanguage is only available under a restrictive license. It's LGPL so long as
you're not selling anything you write. Otherwise you have to purchase a commercial
license. This probably means CleanLanguage will not survive long.
Keean.
Peter Simons [EMAIL PROTECTED] writes:
The problem is not Haskell, nor is it the implementation.
The problem is that beginners, including yours truly, tend
to write awfully inefficient code once you give them a
String and tell them: Here, that's the contents of your
file.
And it's just so
I thought that you could use chained buffers to implement the lazy
lists, that way the top level interface would still be simple.
Also there should be an easy graph-rewrite operation that turns
your 3 sequential operations (in the wc example) into 3 parallel
ones...
put these two together in
On Wed, Oct 06, 2004 at 01:23:56PM -0400, Andre Pang wrote:
I've been watching this thread with interest, and posted my own
thoughts on this thread and Haskell's performance in general as a blog
entry. Rather than repeat it all here, I'll post a link to it:
28 matches
Mail list logo
