inits

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

inits

Spencer Janssen
Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on
#haskell) pointed out that Data.List.inits is rather slow, and
proposed an alternative.  After some collabrative tweaking, we came up
with the following:

> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)

This function seems to perform significantly better.  For example, the
program below takes about 15 seconds with the old inits, and only 3
seconds with the new version (tested with GHC 6.4.1 and -O2).

> main = print $ sum $ map sum $ inits [1..7000]

As this version performs much better and will work as a drop in
replacement, I suggest that it be included in the hierarchical
libraries.


Spencer Janssen
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Sebastian Sylvan
On 4/7/06, Spencer Janssen <[hidden email]> wrote:

> Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on
> #haskell) pointed out that Data.List.inits is rather slow, and
> proposed an alternative.  After some collabrative tweaking, we came up
> with the following:
>
> > inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>
> This function seems to perform significantly better.  For example, the
> program below takes about 15 seconds with the old inits, and only 3
> seconds with the new version (tested with GHC 6.4.1 and -O2).
>
> > main = print $ sum $ map sum $ inits [1..7000]
>
> As this version performs much better and will work as a drop in
> replacement, I suggest that it be included in the hierarchical
> libraries.
>

That's quite a bit faster on my machine as well. I think the following
slight variation may be a bit clearer, though:
inits xs = [] : zipWith take [1..length xs] (repeat xs)

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
Sebastian Sylvan wrote:

> On 4/7/06, Spencer Janssen <[hidden email]> wrote:
>  
>> Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on
>> #haskell) pointed out that Data.List.inits is rather slow, and
>> proposed an alternative.  After some collabrative tweaking, we came up
>> with the following:
>>
>>    
>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>>      
>> This function seems to perform significantly better.  For example, the
>> program below takes about 15 seconds with the old inits, and only 3
>> seconds with the new version (tested with GHC 6.4.1 and -O2).
>>
>>    
>>> main = print $ sum $ map sum $ inits [1..7000]
>>>      
>> As this version performs much better and will work as a drop in
>> replacement, I suggest that it be included in the hierarchical
>> libraries.
>>
>>    
>
> That's quite a bit faster on my machine as well. I think the following
> slight variation may be a bit clearer, though:
> inits xs = [] : zipWith take [1..length xs] (repeat xs)
>
> --
> Sebastian Sylvan
> +46(0)736-818655
> UIN: 44640862
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>  
The length xs wont work on infinite lists.
So you can't do :
   take 100 (length (inits [1..]))

--
Tim Toorop
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Sebastian Sylvan
On 4/8/06, Tim Toorop <[hidden email]> wrote:

> Sebastian Sylvan wrote:
> > On 4/7/06, Spencer Janssen <[hidden email]> wrote:
> >
> >> Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on
> >> #haskell) pointed out that Data.List.inits is rather slow, and
> >> proposed an alternative.  After some collabrative tweaking, we came up
> >> with the following:
> >>
> >>
> >>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
> >>>
> >> This function seems to perform significantly better.  For example, the
> >> program below takes about 15 seconds with the old inits, and only 3
> >> seconds with the new version (tested with GHC 6.4.1 and -O2).
> >>
> >>
> >>> main = print $ sum $ map sum $ inits [1..7000]
> >>>
> >> As this version performs much better and will work as a drop in
> >> replacement, I suggest that it be included in the hierarchical
> >> libraries.
> >>
> >>
> >
> > That's quite a bit faster on my machine as well. I think the following
> > slight variation may be a bit clearer, though:
> > inits xs = [] : zipWith take [1..length xs] (repeat xs)
> >
> > --
> > Sebastian Sylvan
> > +46(0)736-818655
> > UIN: 44640862
> > _______________________________________________
> > Libraries mailing list
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> The length xs wont work on infinite lists.

Ah of course!

/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
In reply to this post by Tim Toorop
Tim Toorop wrote:

> Sebastian Sylvan wrote:
>> On 4/7/06, Spencer Janssen <[hidden email]> wrote:
>>  
>>> Earlier today on the #haskell IRC channel, Tim Toorop (bolrod on
>>> #haskell) pointed out that Data.List.inits is rather slow, and
>>> proposed an alternative.  After some collabrative tweaking, we came up
>>> with the following:
>>>
>>>    
>>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>>>      
>>> This function seems to perform significantly better.  For example, the
>>> program below takes about 15 seconds with the old inits, and only 3
>>> seconds with the new version (tested with GHC 6.4.1 and -O2).
>>>
>>>    
>>>> main = print $ sum $ map sum $ inits [1..7000]
>>>>      
>>> As this version performs much better and will work as a drop in
>>> replacement, I suggest that it be included in the hierarchical
>>> libraries.
>>>
>>>    
>>
>> That's quite a bit faster on my machine as well. I think the following
>> slight variation may be a bit clearer, though:
>> inits xs = [] : zipWith take [1..length xs] (repeat xs)
>>
>> --
>> Sebastian Sylvan
>> +46(0)736-818655
>> UIN: 44640862
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>  
> The length xs wont work on infinite lists.
> So you can't do :
>   take 100 (length (inits [1..]))
>
> --
> Tim Toorop
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
Hmm.. that won't work anyway.
It should have been:   take 100 (inits [1..]) ,  ofcourse.
My bad.

--
Tim Toorop
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[2]: inits

Bulat Ziganshin-2
In reply to this post by Sebastian Sylvan
Hello Sebastian,

Saturday, April 8, 2006, 5:43:44 PM, you wrote:

>> > inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
> inits xs = [] : zipWith take [1..length xs] (repeat xs)

original defintion use a clever trick whci allows to not fully
evaluate list before proceeding. this will require less memory for
such lists as [1..10^6] and moreover it's the only way to work with
infinite lists



--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Nils Anders Danielsson
In reply to this post by Spencer Janssen
On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]> wrote:

>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)

> As this version performs much better and will work as a drop in
> replacement, I suggest that it be included in the hierarchical
> libraries.

It is not a drop in replacement. The original inits is strict, this
one isn't.

The specification of inits (from the Haskell 98 report):

  inits                   :: [a] -> [[a]]
  inits []                =  [[]]
  inits (x:xs)            =  [[]] ++ map (x:) (inits xs)

--
/NAD

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Aaron Denney
On 2006-04-08, Nils Anders Danielsson <[hidden email]> wrote:

> On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]> wrote:
>
>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>
>> As this version performs much better and will work as a drop in
>> replacement, I suggest that it be included in the hierarchical
>> libraries.
>
> It is not a drop in replacement. The original inits is strict, this
> one isn't.
>
> The specification of inits (from the Haskell 98 report):
>
>   inits                   :: [a] -> [[a]]
>   inits []                =  [[]]
>   inits (x:xs)            =  [[]] ++ map (x:) (inits xs)

Is that a property many programs depend on?  I'd actually call that a
bug of the original.

--
Aaron Denney
-><-

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

haskell-2
Aaron Denney wrote:

> On 2006-04-08, Nils Anders Danielsson <[hidden email]> wrote:
>> On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]> wrote:
>>
>>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>> As this version performs much better and will work as a drop in
>>> replacement, I suggest that it be included in the hierarchical
>>> libraries.
>> It is not a drop in replacement. The original inits is strict, this
>> one isn't.
>>
>> The specification of inits (from the Haskell 98 report):
>>
>>   inits                   :: [a] -> [[a]]
>>   inits []                =  [[]]
>>   inits (x:xs)            =  [[]] ++ map (x:) (inits xs)
>
> Is that a property many programs depend on?  I'd actually call that a
> bug of the original.
>

It may break some things:

head (Data.List.inits undefined) is an error

head (New.Spiffy.inits undefined) is []

--
Chris
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
Chris Kuklewicz wrote:

> Aaron Denney wrote:
>  
>> On 2006-04-08, Nils Anders Danielsson <[hidden email]> wrote:
>>    
>>> On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]> wrote:
>>>
>>>      
>>>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>>>>          
>>>> As this version performs much better and will work as a drop in
>>>> replacement, I suggest that it be included in the hierarchical
>>>> libraries.
>>>>        
>>> It is not a drop in replacement. The original inits is strict, this
>>> one isn't.
>>>
>>> The specification of inits (from the Haskell 98 report):
>>>
>>>   inits                   :: [a] -> [[a]]
>>>   inits []                =  [[]]
>>>   inits (x:xs)            =  [[]] ++ map (x:) (inits xs)
>>>      
>> Is that a property many programs depend on?  I'd actually call that a
>> bug of the original.
>>
>>    
>
> It may break some things:
>
> head (Data.List.inits undefined) is an error
>
> head (New.Spiffy.inits undefined) is []
>
>  
Is the head of the inits of undefined really an error?
Since the head of inits []  is also []  ...
But if you really want that undefined to produce an error.. you could just :
        inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn
        inits' _        = undefined

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

haskell-2
Tim Toorop wrote:

> Chris Kuklewicz wrote:
>> Aaron Denney wrote:
>>  
>>> On 2006-04-08, Nils Anders Danielsson <[hidden email]> wrote:
>>>    
>>>> On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]>
>>>> wrote:
>>>>
>>>>      
>>>>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>>>>>          
>>>>> As this version performs much better and will work as a drop in
>>>>> replacement, I suggest that it be included in the hierarchical
>>>>> libraries.
>>>>>        
>>>> It is not a drop in replacement. The original inits is strict, this
>>>> one isn't.
>>>>
>>>> The specification of inits (from the Haskell 98 report):
>>>>
>>>>   inits                   :: [a] -> [[a]]
>>>>   inits []                =  [[]]
>>>>   inits (x:xs)            =  [[]] ++ map (x:) (inits xs)
>>>>      
>>> Is that a property many programs depend on?  I'd actually call that a
>>> bug of the original.
>>>
>>>    
>>
>> It may break some things:
>>
>> head (Data.List.inits undefined) is an error
>>
>> head (New.Spiffy.inits undefined) is []
>>
>>  
> Is the head of the inits of undefined really an error?
> Since the head of inits []  is also []  ...
> But if you really want that undefined to produce an error.. you could
> just :
>        inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn
>        inits' _        = undefined
>
>

Exactly.  Now inits' *is* a drop in replacement for inits.

--
Chris
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
In reply to this post by Aaron Denney
Aaron Denney wrote:

> On 2006-04-08, Nils Anders Danielsson <[hidden email]> wrote:
>  
>> On Fri, 07 Apr 2006, "Spencer Janssen" <[hidden email]> wrote:
>>
>>    
>>>> inits xs = [] : (zipWith take [1..] $ map (const xs) xs)
>>>>        
>>> As this version performs much better and will work as a drop in
>>> replacement, I suggest that it be included in the hierarchical
>>> libraries.
>>>      
>> It is not a drop in replacement. The original inits is strict, this
>> one isn't.
>>
>> The specification of inits (from the Haskell 98 report):
>>
>>   inits                   :: [a] -> [[a]]
>>   inits []                =  [[]]
>>   inits (x:xs)            =  [[]] ++ map (x:) (inits xs)
>>    
>
> Is that a property many programs depend on?  I'd actually call that a
> bug of the original.
>
>  
If you know anything that is bad about the definition above, please tell.
But so far I haven't found _anything_ the original inits performs better on.

I profiled some expressions. And as you can see, the original inits
seems to create alot of junk.
I did profiling with   print ( inits [1..5000]),  with which the
original version is just a tad slower.
But with print ( length (inits [..]))   I couldn't even compare the
original version to this one.
The old had problems to calculate  length (inits [1..20000])  while this
one easilly did length (inits [1..500000]).

The output is in the pdf files. _Note_ that the length is of [1..500000].
I couldn't be bothered to run my computer for some hours to let the
original version of inits calculate it.
And this version of inits didn't even show up on the graph when
calculating [1..20000]  in case you wonder why its not there.





_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

inits-print-5000.pdf (3K) Download Attachment
inits-orig-print-5000.pdf (3K) Download Attachment
inits-orig-length-20000.pdf (4K) Download Attachment
inits-length-500000.pdf (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: inits

Aaron Denney
In reply to this post by haskell-2
On 2006-04-08, Chris Kuklewicz <[hidden email]> wrote:

>> Is the head of the inits of undefined really an error?
>> Since the head of inits []  is also []  ...
>> But if you really want that undefined to produce an error.. you could
>> just :
>>        inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn
>>        inits' _        = undefined
>>
>>
>
> Exactly.  Now inits' *is* a drop in replacement for inits.

Right, but the new spiffy inits seems to be a strict superset.  Does
anything plausibly depend on the strictness of the original.  I think it
was written that way for clarity, not for the strictness properties.

--
Aaron Denney
-><-

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

haskell-2
Aaron Denney wrote:

> On 2006-04-08, Chris Kuklewicz <[hidden email]> wrote:
>>> Is the head of the inits of undefined really an error?
>>> Since the head of inits []  is also []  ...
>>> But if you really want that undefined to produce an error.. you could
>>> just :
>>>        inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn
>>>        inits' _        = undefined
>>>
>>>
>> Exactly.  Now inits' *is* a drop in replacement for inits.
>
> Right, but the new spiffy inits seems to be a strict superset.  Does
> anything plausibly depend on the strictness of the original.  I think it
> was written that way for clarity, not for the strictness properties.
>

I have nothing that depends on the difference.

And it really only affects (inits undefined).

There is a certain progressions to this though

(A) inits undefined      is undefined
(B) inits [undefined]    is []:[undefined]
(C) inits [1,undefined]  is []:[1]:[1,undefined]

The original replacement made (A) behave like (B), which breaks the nice
progression.

--
Chris
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
In reply to this post by Aaron Denney
Aaron Denney wrote:

> On 2006-04-08, Chris Kuklewicz <[hidden email]> wrote:
>  
>>> Is the head of the inits of undefined really an error?
>>> Since the head of inits []  is also []  ...
>>> But if you really want that undefined to produce an error.. you could
>>> just :
>>>        inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn
>>>        inits' _        = undefined
>>>
>>>
>>>      
>> Exactly.  Now inits' *is* a drop in replacement for inits.
>>    
>
> Right, but the new spiffy inits seems to be a strict superset.  Does
> anything plausibly depend on the strictness of the original.  I think it
> was written that way for clarity, not for the strictness properties.
>
>  
The inits' _ = undefined  can be left out, but may be useful to some
clarity.
On the other hand, I think the new spiffy inits is quite clear once you
notice why its  map (const xn) $ undefined:xn

This version doesn't use a weird recursive function.
Its just..  the definition of inits I think.

first element of inits,  take the first element.
2nd element of inits,  take the first plus the next element
...

But that's just my logic... probably why I wrote it like this in the
first place
  ( just wanted to see if I could write the inits without using a book ;)  )
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Josef Svenningsson
On 4/8/06, Tim Toorop <[hidden email]> wrote:
> On the other hand, I think the new spiffy inits is quite clear once you
> notice why its  map (const xn) $ undefined:xn
>

I think it would be even clearer if it were defined like this:

> inits xs = zipWith take [0..] $ map (const xs) xs

That way you don't have this ugly special case for the first element
in the list. But there is an even better advantage: it is strict
again! So it's termination properties are exactly like the Prelude
one. This version *can* be used as a drop-in replacement of the
Prelude version.

Cheers,

/Josef
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Tim Toorop
Josef Svenningsson wrote:

> On 4/8/06, Tim Toorop <[hidden email]> wrote:
>  
>> On the other hand, I think the new spiffy inits is quite clear once you
>> notice why its  map (const xn) $ undefined:xn
>>
>>    
>
> I think it would be even clearer if it were defined like this:
>
>  
>> inits xs = zipWith take [0..] $ map (const xs) xs
>>    
>
> That way you don't have this ugly special case for the first element
> in the list. But there is an even better advantage: it is strict
> again! So it's termination properties are exactly like the Prelude
> one. This version *can* be used as a drop-in replacement of the
> Prelude version.
>
> Cheers,
>
> /Josef
>  
Yes it is very clear ... except for the fact that it doesn't work correctly.
It misses the last element.
now we could write
      inits2' xn = (zipWith take [0..] $ map (const xn) xn ) ++ [xn]
Though I dont know if this really is clearer, and it seems to make the
garbage collector work slightly more
And which I think does exactly the same as
      inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Aaron Denney
On 2006-04-08, Tim Toorop <[hidden email]> wrote:

> Josef Svenningsson wrote:
>> On 4/8/06, Tim Toorop <[hidden email]> wrote:
>>  
>>> On the other hand, I think the new spiffy inits is quite clear once you
>>> notice why its  map (const xn) $ undefined:xn
>>>
>>>    
>>
>> I think it would be even clearer if it were defined like this:
>>
>>  
>>> inits xs = zipWith take [0..] $ map (const xs) xs
>>>    
>>
>> That way you don't have this ugly special case for the first element
>> in the list. But there is an even better advantage: it is strict
>> again! So it's termination properties are exactly like the Prelude
>> one. This version *can* be used as a drop-in replacement of the
>> Prelude version.
>>
>> Cheers,
>>
>> /Josef
>>  
> Yes it is very clear ... except for the fact that it doesn't work correctly.
> It misses the last element.
> now we could write
>       inits2' xn = (zipWith take [0..] $ map (const xn) xn ) ++ [xn]
> Though I dont know if this really is clearer, and it seems to make the
> garbage collector work slightly more
> And which I think does exactly the same as
>       inits' xn@(_:_) = zipWith take [0..] $ map (const xn) $ undefined:xn

Yes, but is there any real need to use the ugly pattern syntax?

Surely

inits xs = zipWith take [0..] $ map (const xs) (undefined:xs)

(I still think letting head $ inits undefined be [] rather than
undefined is better than the current def.)

--
Aaron Denney
-><-

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Josef Svenningsson
In reply to this post by Tim Toorop
On 4/9/06, Tim Toorop <[hidden email]> wrote:
> Yes it is very clear ... except for the fact that it doesn't work correctly.
> It misses the last element.

Ah, yes. My bad.

/Josef
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: inits

Josef Svenningsson
In reply to this post by Aaron Denney
On 4/9/06, Aaron Denney <[hidden email]> wrote:
> inits xs = zipWith take [0..] $ map (const xs) (undefined:xs)
>
Nicest version so far!

> (I still think letting head $ inits undefined be [] rather than
> undefined is better than the current def.)
>
Yes, from a termination point of view it surely seems better with the
lazy version. But I believe that this is the wrong way of seeing it.
These termination issues are hardly any problem in every-day
programming. But what few people here seem to realize is that a change
in the strictness of a function will change the space behaviour of a
program. I use that as a rule of thumb when inspecting Haskell code:
whenever the strictness changes that will lead to a change in memory
consumption. So changing inits to a lazier version will  not affect a
lot of program termination-wise but it will have effects on the space
consumption. Whether these effects will be good of bad depends on the
program, but the fact remains, there will be a change. I think this is
unwelcome and that's why I think that the strictness properties of the
Prelude functions should be preserved.

Cheers,

/Josef
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123