Would you recommend this library as a solution for extensible records?

[3noch]

Dict seems like it's a decent candidate for extensible records. What do you think? If so, would it be possible to integrate lenses?

[winterland1989]

Well, like document implied, Dict is read only hetero-array. so it's not so useful when you need updatable extensible record, what's your use case then?

[3noch]

Sorry I suppose DynDict would be the potential candidate.

[3noch]

Although I'm curious now since I doubt DynDict is actually mutating memory: is DynDict just Dict with setter operations?

Oh I see: Dict uses a more efficient array structure which is costly for updates. Nevermind.

[3noch]

Essentially my use case is just trying to find tools for extensible records. Vinyl is touted as a common solution and your benchmarks are compared with Vinyl so I thought the feature set might overlap a bit. Also it seems that Vinyl has a lot of boilerplate and I don't know how to use it with Symbols.

[winterland1989]

Yes, Vinyl is too heavy for my usage. i'll try provide something like[keyL|foo|] in next release, which return a van laarhoven lense after get spliced, patches welcomed!

[3noch]

Ah that would be amazing! I'm assuming it would work on DynDict since Dict it seems can't have lenses since it doesn't support updates. Is that true? Also, it seems you are implying that using DynDict as tool for extensible records is a legitimate use-case?

[winterland1989]

yes, it is a legitimate use case of course ; )

[3noch]

Excellent. I'm not terribly familiar with the territory but it does somewhat worry me that DynDict has O(n) lookup. Is that the same for other extensible record solutions? Certainly Haskell's native records are O(1) lookup.

[winterland1989]

I searched for all solution once and implement DynDict as Seq first which has O(log(n)) access time in theory, but benchmark showed the constant factor is too large for small hetero-list, so i switch back to linked-list based solution.

Haskell's native records are O(1) lookup.

That's why i borrowed Dict type which use boxed array just like a real record, anyway if you think a O(n) update is acceptable, i can also provide a update operation, which makes Dict has the same character as a records.

[3noch]

Why would Dict need O(n) update if it has O(1) lookup? For copying the array?

[winterland1989]

Yes, this is the same for record IIRC.

[3noch]

If you gave Dict a method of doing update, then it seems you could achieve similar performance asymptotics to built-in records/tuples: O(1) lookup and O(n) update (where n is the number of fields). This seems an ideal situation for extensible records. What then would meaningfully differentiate Dict from DynDict?

[winterland1989]

Well, theoretically Dict and DynDict have different asymptotic complexity:

• DynDict will have O(m) access, O(n-m) update.
• Dict have O(1) access, O(n) update.

But in such a small n(< 20), these difference is so small to benchmark. Overall i'm agree with you that Dict may suit extensible records better, so i will add update operation, but i need construct some meaningful benchmarks.

[3noch]

The README says that "Dict has O(1) get". Is that not true?

[winterland1989]

The README says that "Dict has O(1) get". Is that not true?

sorry i make a mistake, see edited above.