Greg Buchholz <[EMAIL PROTECTED]> writes:
> I've been looking at the other shootout results (with the hope of
> learning something about making haskell programs faster/less memory
> hungry) and I couldn't quite figure out why the "Hashes, part II" test
> comsumes so much memory ( http://shooto
Ketil Malde <[EMAIL PROTECTED]> writes:
> To get memory consumption down, I tried a strict "update" function:
>update k fm = let x = (get hash1 k + get fm k)
> in x `seq` addToFM fm k x
> which slowed the program down(!),
I wonder if this isn't due to never evaluating the
On 2004-10-06, Glynn Clements <[EMAIL PROTECTED]> wrote:
> I can't comment on nhc98, but the Haskell98 standard doesn't include
> any mechanism for binary I/O.
Ouch. That seems like a major oversight to me. Will there be any
effort to fix that in the future?
-- John
__
I take it that the extra case always fails but forces
the arguments to be evaluated? Nice trick.
Thanks!
--wgm
--- [EMAIL PROTECTED] wrote:
>
> I added two lines to your code:
>
> iterate2 f x n | seq f $ seq x $ seq n $ False =
> undefined
> iterate2 f x n = --- as before
>
> rk4Next f h (
John Goerzen <[EMAIL PROTECTED]> writes:
> On 2004-10-06, Glynn Clements <[EMAIL PROTECTED]> wrote:
> > I can't comment on nhc98, but the Haskell98 standard doesn't include
> > any mechanism for binary I/O.
>
> Ouch. That seems like a major oversight to me. Will there be any
> effort to fix tha
Malcolm Wallace wrote:
> > > I can't comment on nhc98, but the Haskell98 standard doesn't include
> > > any mechanism for binary I/O.
> >
> > Ouch. That seems like a major oversight to me. Will there be any
> > effort to fix that in the future?
>
> Note that, on Unix-like systems, there is no
On 29/09/2004, at 8:41 AM, Graham Klyne wrote:
I can see that this requires the original file to be kept for 3-time
scanning, so enough memory for the entire file will be required. Is
that *the* problem to which you allude? I can't see any other problem
here. And why would this put Haskell a
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:
>
> http://www.algorithm.com.
Ketil Malde wrote:
> Ketil Malde <[EMAIL PROTECTED]> writes:
>
> > To get memory consumption down, I tried a strict "update" function:
>
> >update k fm = let x = (get hash1 k + get fm k)
> > in x `seq` addToFM fm k x
>
> > which slowed the program down(!),
Yes that fi
I wouldn't write off Haskell so quickly. All of what Shoeb describes
concerning DSL issues might be much more easily solved in Haskell, and
will certainly be more flexible than a hard-wired approach. The J2EE
interface might be ugly, but if the functionality needed is not too
great it might n
Yes, I agree, and didn't mean to write off Haskell (at which, I'm
completely a newbie, trying to learn, and thankful for your book!).
However, I'm a Java pro, and there are many technical issues on the
Java side that scream at me to keep out of the native arena, especially
in a J2EE container e
Ok, I understand. I don't know much at all about J2EE, in fact! I
would just hate to see an interesting project be abandoned if all that
is needed is a simple way to invoke the Haskell code with a string
argument, say. Perhaps Shoeb can tell us more about what he needs.
-Paul
Doug Kirk wro
On Tuesday 05 October 2004 23:33, Bhinderwala, Shoeb wrote:
> I came across a few papers that talk about writing a DSL with Haskell
> as the underlying support language. How is this done. Is it possible
> to create a sort of domain specific business scripting language
> easily. How does that then c
This might be an interesting way to highlight the beauty and brevity
of Haskell. Has anyone written a great 500-line Haskell program they
want to submit?
peace,
isaac
http://developers.slashdot.org/article.pl?sid=04/10/06/1530218&tid=156&tid=8
"Be part of the Open Source Annual 2005 and ent
Andy,
For the asteroids game, I just call GHC's System.Mem.performGC every
frame and it seems to run ok. It's a very simple game, my 2.6Ghz P4
system walks all over it and the FPS counter seems to bounce around from
about 150 to 300.
I would imagine it's spending all it's time in the big XFillR
15 matches
Mail list logo