--- Robert Dockins [EMAIL PROTECTED] wrote:
Then perhaps it is worth considering having multiple
implementations and
choosing between them with pragmas and/or command
line switches (with
a sensible default naturally). Maybe doubly linked
lists are not a
great idea, but if we had a
On Wed, 13 Oct 2004, Shawn Garbett wrote:
Lists are an integral part of the Haskell language,
and in fact most languages have some version of list
at a fundamental level. Here's an interesting (not
necessarily useful!) shift of viewpoint: What if List
were a type class?
Then we'd need
Shawn Garbett [EMAIL PROTECTED] writes:
viewpoint: What if List were a type class?
Or, what if String were one? Could we have painless read/show with
arrays of Char, as well as lists, for instance?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
--- Ketil Malde wrote:
Or, what if String were one? Could we have painless read/show with
arrays of Char, as well as lists, for instance?
--- end of quote ---
I think with a decent set of type classes for collections, better handling of strings
would come for free. If any list function could
On 07 October 2004 18:23, Ketil Malde wrote:
Couldn't readFile et al. provide the standard interface, but use
hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains?
readFile does do buffering behind the scenes, that's not the problem.
The problem is doing the computation on a [Char]
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That would let us do nice things like
have O(1)
On Fri, Oct 08, 2004 at 08:35:40AM -0400, Robert Dockins wrote:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked
lists doubly-linked and circular.
Erm, this just increases overhead, and file access is linear
anyway. Singly linked is good enough. What would make a difference
is if each 'node' in the listwas allowed to be larger that '1'
item. For example reading a file with 4k buffers, would work much better
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That would let us do nice things like
have O(1)
At some point in the past, someone wrote:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular. That
William Lee Irwin III [EMAIL PROTECTED] writes:
Actually, I've been wondering about this. If my understanding is
correct, Haskell lists are basicly singly-linked lists of cons cells (is
that correct?) A simple (I think) thing to do would be to make the
lists doubly-linked and circular.
William Lee Irwin III [EMAIL PROTECTED] writes:
Ugh, lousy cache properties... try rank-ordered B+ trees. There are
probably better choices than that even. It's probably best Simon point
us to references to what's actually useful here.
On Fri, Oct 08, 2004 at 03:55:05PM +0200, Ketil Malde
Doubly linked lists do not work very well in functional languages.#
when you have a list [1,2,3] and you prepend a value [9,1,2,3] the language
relies on the fact that the list tail [1,2,3] is not chainged by this operation.
This means the list can be prepended-in-place. With a doubly linked list
On Fri, Oct 08, 2004 at 12:43:45PM -0400, Robert Dockins wrote:
x = [3,5,7]
primes = 2:x
odds = 1:x
You can't do sharing like this if your lists are doubly-linked; lots
of cool algorithms depend on this sharing.
That constraint makes various other things painful. I suppose there is
no
Here is a quick fix for the Random Numbers category. Looks like a
classic space-leak, again on the arithmetic operations. Speeds up
results for me about 6X and brings memory usage down out of the
stratosphere.
w/o strictness:
~/shootout$ time random 90 +RTS -K3200
75.544410151
real
15 matches
Mail list logo
