Eager seq ix

[treeowl]

• Make ix look up eagerly for Seq.
• Make ix use !? for vectors, which should eventually make those lookups eager too.

[phadej]

Eager here means that we don't retain the original sequence/vector, i.e. f x is f <element value> and not f <think to lookup element>?

If my understanding is right, could you amend commit message(s) with that, so it would be clearer what these changes do.

[phadej]

Is here impossible to seq things to avoid thunk, Would

let x = Seq.index m i `seq` (f x <&> ...)

do anything?

[treeowl]

Using seq with index would force too much, forcing not only the lookup but also the element itself.

[phadej]

I see. as later then 0.5.8 containers are bundled with GHC-8.2, I don't think we need to do here anything. (If someone have problems due this lazyness, and they could upgrade GHC or/and containers)

[treeowl]

@phadej Do you mean we shouldn't worry about the leak for older containers? I agree. Trying to plug it in that context will be very inefficient when f is actually strict.

[phadej]

Please add changelog entry. If you explain what this change means there (not just saying eager seq ix), then we don't need to repeat the explanation in commit messages.

[treeowl]

@phadej For Data.Sequence, lookup isn't O(1), and this PR can make lookups happen when they're not actually necessary. I can write some fancy rewrite rules to take care of the case where ix is (obviously) used to set without inspecting. This involves a dance with non-linear patterns and carefully buried bottom values. But I'm kind of thinking all that gunk would fit better in containers than in lens.

[RyanGlScott]

What is the status of this PR? If I'm reading correctly, this is very nearly done modulo documentation/changelog concerns. (I'm asking since I'm doing a roundup of recent PRs before an upcoming lens release.)

[treeowl]

Haven't looked at this in ages. Can try to look today.

[phadej]

ping @treeowl

[treeowl]

Pong! I will try to look at this today.