On Mon, Oct 11, 2004 at 09:53:16PM -0400, Scott Turner wrote:
> I tried using continued fractions in a "spiffy lazy list" implementation a
> while ago. Never got them working as well as expected.
> Evenutally I realized that calculating with lazy lists is not as
> smooth as you might expect.
> Fo
On 2004 October 09 Saturday 15:33, William Lee Irwin III wrote:
> So, I discovered that simple continued fractions are supposed to be
> spiffy lazy lists and thought I'd bang out some continued fraction code.
> But then I discovered ContFrac.hs and couldn't really better it. Of
> course, I went abo
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 mu
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?
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 t
At 10:47 08/10/04 +0100, Malcolm Wallace wrote:
John Goerzen <[EMAIL PROTECTED]> writes:
> My initial thought was to use the cpp-style ifdefs I've seen elsewhere
> to mask those unsupported features on those particular systems. But
> Hugs at least doesn't support that, and I've found it extremely
Peter Simons <[EMAIL PROTECTED]> writes:
> http://cryp.to/blockio/docs/tutorial.html
Pretty neat. Wouldn't it be a nice addition to the
Tutorials section on the Haskell Bookshelf?
Note: as I gather, GHC's lists are not doubly linked.
--
Feri.
___
H
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 i
"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
>No, you still have to copy "" so you can change the tail pointer
Do you? If "" is treated as a single buffer contents (IE implemented
as a UArray Int Char for example) then as our 'new' list implementation#
can have cells which are single elements of buffers of elements, we
simply 'cons'
> It is, of course, trivial to implement this for lists. I've run into
> a snag, however, when trying to implement this for Arrays (as in
> Data.Array) - I can't seem to find a way to represent an empty array,
> which makes implementing 'empty' and 'null' impossible. Suggestions?
>
Empty arrays
> This would also benefit string processing... Imagine:
>
> test = "" ++ ""
>
> This could be implented as two list cells, one for each string, anf
> the cost of the "++" becomes the same as the cost of ":"
No, you still have to copy "" so you can change the tail pointer -
but at lea
12 matches
Mail list logo
