Proposal: Make GHC.Arr.listArray slightly stricter to allow fusion

[David Feuer]

To be really specific, in case anyone can learn anything from me
embarrassing myself:

take uses a neat little trick to avoid blowing up on a bottom-terminated
list: instead of counting down to 0, it counts down to 1. This lets it stop
just short of trouble. The same technique should work for listArray.
On Nov 13, 2014 11:20 AM, "David Feuer" <david.feuer at gmail.com> wrote:

> Oh, I think I am a fool! That'll show me to post to the list at such an
> absurd hour.
>
> On Thu, Nov 13, 2014 at 6:33 AM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Hi,
>>
>>
>> Am Donnerstag, den 13.11.2014, 05:22 -0500 schrieb David Feuer:
>> > Currently, GHC.Arr.listArray is pretty lazy:
>> >
>> > listArray (1,3) $ [1,2,3] ++ undefined
>> >
>> > will work perfectly fine.
>> >
>> > This is actually lazier than the current array:
>> >
>> > array (1,3) $ [(1,1), (2,2), (3,3)] ++ undefined = undefined
>> >
>> > Unfortunately, I don't think it's possible to make listArray fuse with
>> > a list producer while preserving quite that level of laziness. If
>> > we're willing to be slightly stricter, however, I think everything
>> > works. Specifically, I propose that we allow
>> >
>> > listArray (length xs) (xs ++ _|_) = _|_>
>>
>> given that
>>         listArray (1,3) xs = listArray (1,3) (take 3 (xs))
>> and take can fuse with a good producer (can it?), I would expect that
>> listArray can be made to fuse as good or as bad as take.
>>
>> What precisely is the problem with the more lazy listArray?
>>
>> Greetings,
>> Joachim
>>
>>
>>
>>
>>
>> --
>> Joachim “nomeata” Breitner
>>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/c9bd6d7a/attachment-0001.html>