>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'
> 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
On Fri, 8 Oct 2004, Marcin 'Qrczak' Kowalczyk wrote:
> If the representation of some lists was changed, it would complicate
> all code which works on lists. Or maybe only polymorphic code, but
> it's still much. I don't believe it would be practical.
That's true in OCaml but not in the STG-machin
At some point in the past, someone's attribution was stripped from:
>> It can't be transparent. A different type for semi-packed strings,
On Fri, Oct 08, 2004 at 07:28:53PM +0100, MR K P SCHUPKE wrote:
> Again I disagree... I dont see why you cannot change the "implementation"
> of lists without c
>In general only specific *code* can be compiled more efficiently.
I disagree - If GHC optimised as much as is _possible_ the code would
be as fast and use as little memory as hand coded 'C'
>It can't be transparent. A different type for semi-packed strings,
Again I disagree... I dont see why yo
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
> This sounds like the best idea to me... with each list cell being a
> full buffer you could effectively write nieve [Char] code and have it
> implemented in about as fast a way as possible...
If the representation of some lists was changed, it would co
> - take this further and have list cells with 2 (or more) unboxed
>characters, or even a full buffer.
This sounds like the best idea to me... with each list cell being a
full buffer you could effectively write nieve [Char] code and have it
implemented in about as fast a way as possible...
A
On 08 October 2004 13:36, Robert Dockins wrote:
> BTW can you give some references to these known techniques?
Hmm, well here's some folklorish ideas. I'm sure there are references
for most of these, but I don't know them off hand.
- Have another list constructor that has 2 (or more) elements.
