3 ms·
The paper notes a limitation this approach has with arrays: once you stop mutating an array and want to make a "pure" version that is useable outside ST, you ha
by danidiaz 6y ago
The paper notes a limitation this approach has with arrays: once you stop mutating an array and want to make a "pure" version that is useable outside ST, you have to choose between the safe but slow option of copying the array, and the true to its name "unsafeFreeze" function:
> The implementation of arrays is straightforward. The only complication lies with freezeArray, which takes a mutable array and returns a frozen, immutable copy. Often, though, we want to construct an array incrementally, and then freeze it, performing no further mutation on the mutable array. In this case it seems rather a waste to copy the entire array, only to discard the mutable version immediately thereafter.
> The right solution is to do a good enough job in the compiler to spot this special case. What we actually do at the moment is to provide a highly dangerous operation unsafeFreezeArray, whose type is the same as freezeArray, but which works without copying the mutable array. Frankly this is a hack, but since we only expect to use it in one or two critical pieces of the standard library, we couldn't work up enough steam to do the job properly just to handle these few occasions.
It seems that the recent addition of linear types to GHC 9.0 will enable "freeze" operations that are both fast and safe: http://hackage.haskell.org/package/linear-base http://hackage.haskell.org/package/linear-base http://hackage.haskell.org/package/linear-base-0.1.0/docs/Data-Array-Mutable-Linear.html http://hackage.haskell.org/package/linear-base-0.1.0/docs/Da...