There are three pieces to this story:
- read a config file into some structure
- query/modify elements of that structure
- write structure out to a file
Create a data structure (analogous to a class with no methods) and functions
to query/manipulate that structure. Nested FiniteMaps might be a
On Wed, Sep 29, 2004 at 08:29:47PM +, John Goerzen wrote:
So I am thinking about a ConfigParser for Haskell. The first thing that
occured to me is that Haskell has no OO features, so I'm not sure what
is the best way to handle the class and its various methods.
The next thing that
Thanks... it's interesting to see that functional languages in general, and
especially ML derivatives, do show comparable performance to languages like
Python, Perl and Java.
But what I was really after was an indication of trends. The impression I
have is that longer the term trend is to
At 09:01 30/09/04 +0100, Bayley, Alistair wrote:
Ben suggested using Parsec for reading the config file. Parsec is a fine
library, but there is a learning curve, and you might find it quicker to do
the parsing yourself, if it's very simple. Your call.
Hmmm... Parsec *can* be simple too. Here's
Just out of interest, I ran all of these suggested variations of
the word count solution in Haskell head-to-head against each other.
Here are the results, in seconds, on my machine (2.4GHz x86/Linux)
for the suggested input (N=500) from the shootout site. All Haskell
versions were compiled with
On Thu, Sep 30, 2004 at 11:26:15AM +0100, Malcolm Wallace wrote:
Those marked with a * gave the wrong number of words. The really
interesting thing is that Tomasz's solution is twice as fast as the
standard Gnu implementation!
That's probably because Gnu wc is locale aware.
Best regards,
Tom
Sure. Learning Parsec took me a few hours, whereas John's parsing task might
be done in much less time, if it's simple enough. OTOH, there's value in
being able to use Parsec, so it's a good excuse to learn.
-Original Message-
From: Graham Klyne [mailto:[EMAIL PROTECTED]
Sent: 30
On 2004-09-30, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
You can use make -k to keep going, I seem to remember, or use -pgmltrue,
Those tricks got me farther. Now I'm on the target and stuck at:
gmake[5]: Entering directory
`/home/jgoerzen/programs/unreg/ghc-6.2.1/ghc/rts/gm
p/mpn'
m4
John (and Haskell community),
I just subscribed to the Haskell mailing list the other day and this
posting grabbed my attention. I've been workin with Python for a few
years now and have recently decided to try to expand my horizons to
Haskell (and OCaml). I love Python, but I feel like I
On Thursday 30 September 2004 07:54 am, Jeremy Jones wrote:
John (and Haskell community),
I just subscribed to the Haskell mailing list the other day and this
posting grabbed my attention. I've been workin with Python for a few
years now and have recently decided to try to expand my horizons
On Thu, Sep 30, 2004 at 11:26:15AM +0100, Malcolm Wallace wrote:
Just out of interest, I ran all of these suggested variations of
the word count solution in Haskell head-to-head against each other.
Here are the results, in seconds, on my machine (2.4GHz x86/Linux)
for the suggested input
On Thu, Sep 30, 2004 at 09:49:46AM -0400, Kevin Everets wrote:
I took Georg's, fixed the word count logic and added prettier
printing, and then combined it with Sam's main (which I find more
elegant, but others may find less straightforward). I think it
strikes a good balance between
How can anyone stay away from such a deliciously pointless
waste of time as implementing a wc(1) derivate? :-)
Here is my attempt:
import IO
type Count = Int
data CountingState = ST !Bool !Count !Count !Count
deriving (Show)
initCST = ST True 0 0 0
Sam Mason wrote:
You probably want some strictness annotations in there. . .
Now we're getting somewhere. When I replace the tuples with my own
(strict) data structure, it gets about 7.5 times faster than the original
shootout example (or about 24 times faster than the version with
At 16:56 30/09/04 +0200, Tomasz Zielonka wrote:
Then how about a solution like this: I took your program but used
my fast fileIterate instead of ,,foldl over getContents''.
I also added {-# OPTIONS -funbox-strict-fields #-}, and played a bit
to get the best optimisations from GHC.
It's about 7
On Thu, Sep 30, 2004 at 05:40:58PM +0100, Graham Klyne wrote:
2. Your fileIterator certainly looks nicer (to me) than your other
solution, but...
It looks nicer to me too.
Tagging along with this debate, I found myself wondering if, in order to
get performance comparable to other
At 19:39 30/09/04 +0200, Tomasz Zielonka wrote:
What I like about GHC is that I can start from simple, high-level,
sometimes slow solutions, but if there are efficiency problems, there is
a big chance that I can solve them without switching the language.
That's a very good point, I think. One to
Hi folks,
On Thu, 30 Sep 2004 01:02:54 +0100, Sam Mason [EMAIL PROTECTED] wrote:
Greg Buchholz wrote:
The algorithm isn't correct (it counts spaces instead of words), but
anyone have advice for improving its performance?
You probably want some strictness annotations in there. . .
snip
Last night
Malcolm Wallace wrote:
Here are the results, in seconds, on my machine (2.4GHz x86/Linux)
for the suggested input (N=500) from the shootout site. All Haskell
versions were compiled with ghc-5.04.2 -O2.
I thought I'd take a stab at timing a few of the examples with
different compiler
Hi Greg
Anyone have an explaination for the 2x speed
increase for running Kevin's version with '+RTS -G1'?
+RTS -Sstderr -RTS and +RTS -sstderr -RTS will probably indicate why.
I'd be surprised if the amount of data copied for the semi-space
collector isn't much less than for the generational.
Andrew Cheadle wrote:
+RTS -Sstderr -RTS and +RTS -sstderr -RTS will probably indicate why.
I'd be surprised if the amount of data copied for the semi-space
collector isn't much less than for the generational.
Ahh. Data copied with '-G1' = 58MB vs. 203MB without. For posterities
sake,
Georg Martius wrote:
Some more general comment: The code for the shootout doesn't need to be
extremly fast in my eyes, it needs to be elegant and reasonable at
performance and memory consuptions (In this order). I don't want to say
that Thomaszs solution is bad, but it is not a typical
jgoerzen:
On 2004-09-30, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
You can use make -k to keep going, I seem to remember, or use -pgmltrue,
Those tricks got me farther. Now I'm on the target and stuck at:
gmake[5]: Entering directory
23 matches
Mail list logo
