Add simple builder

[paluh]

I'm providing a simple builder implementation which was shortly discussed here: #115

[JordanMartinez]

Any updates on this? Or would it be best to turn this into a library so others can use it sooner and then merge it into this project after its API gets fleshed out a bit more?

[garyb]

Maybe we should add a warning that this isn't suitable for building large arrays, since it's not stack safe? (The same could be said for the Record case, but is perhaps less likely there since records won't tend to have thousands of fields).

[JordanMartinez]

Oh, good point.

[JordanMartinez]

Couldn't this be made stack-safe if one used https://github.com/safareli/purescript-stacksafe-function ?

[paluh]

@JordanMartinez I think it should be stack safe then. Should I reimplement it? Isn't dependency on stacksafe-function a problem?

[hdgarrood]

I think stack safety is a requirement, but a dependency on stacksafe-function is not possible since it’s not in core. I’m not particularly keen on adding stacksafe-function to core either. We could potentially use a similar approach here.

I think this needs benchmarks too, because if it turns out this doesn’t perform well in realistic examples, then I don’t think we should add it.

[hdgarrood]

Could you use the ASCII versions of syntax like ->, ::, and forall please?

[JordanMartinez]

I think stack safety is a requirement, but a dependency on stacksafe-function is not possible since it’s not in core. I’m not particularly keen on adding stacksafe-function to core either. We could potentially use a similar approach here.

Right, because it's not in core. If we do decide to support this here, how would we make the function stack-safe? If we don't support it here, then couldn't this code exist as a separate library that does depend on stacksafe-function? I would prefer it doesn't do that, but something worth discussing.

[natefaubion]

If you make it stack safe, it's not totally clear to me what the advantage of this is then. You are already allocating a closure for every cell, and if you make it stack safe you will have to suspend those closures in an additional data structure, which is either going to just be another Array, or a tree of some kind. If it's a tree, you'll have to consume it in a loop and make additional allocations for stack. That's a lot of overhead just to build an Array.

[hdgarrood]

That’s the conclusion I was coming to as well. Maybe we just shouldn’t add this then? Can anyone provide a convincing example where this API is preferable to both the normal array API and the STArray API? If not I don’t think this approach earns a spot here.

[hdgarrood]

Or do you think a non stack safe version still has something going for it despite the lack of stack safety? I just think that it could be quite surprising for this API to not be stack safe.

[natefaubion]

I don’t think we should add it without evidence that it’s a preferable alternative along some metric.

[natefaubion]

Or do you think a non stack safe version still has something going for it despite the lack of stack safety?

I just mean that the primary advantage appears to be something lightweight and pure. I could see adding an API on those merits. Accounting for stack-safety makes it anything but lightweight, however, both in implementation and overhead. If stack safety is critical (and I agree, for Array it probably is), then we shouldn't add it without evidence that it still satisfies a desirable space over ST, pure Array operations, or List/CatList conversions.

[JordanMartinez]

I'd imagine that the desire for a Builder API for Array is partly because it requires less learning to use.

Regardless, should we close this issue?

[hdgarrood]

I'm not sure I agree that it requires less learning, but yeah, I think we can close this PR (and the associated issue). Thank you anyway @paluh!

[paluh]

Thanks for all the reviews and discussion.

P.S. Maybe I release something small like overflowing-array-builder instead ;-)