> 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-0.1.0/docs/Da...
Skimming this article really made me appreciate the compactness and clarity of do-notation (although hard-core Haskellers will object that it hides what really is going on)
I've never seen anybody say this. Many people say that when learning you must avoid it a few times to understand it, but I never saw anybody claiming it hides things for experienced developers.
Also, I think the idea is very far fetched, expanding do notation on your head when reading code is one of the minimum skills to make proper use of the language, thus it can't hide anything to hard-core Haskellers. Anyway, if you think your program is better structure using do, use it and don't stop to listen to criticism.
Also GHC now has features to revert all the bad structure problems cited there.
There is no wildcard advice of "use do notation" or "avoid do notation" possible. It's an incredibly handy tool, but you need to decide for yourself if it improves your code or not.
Modern outline versions of these fonts have since become available and this typically isn't a problem with newly generated files. (You can make this happen, but by default everything uses outline postscript fonts these days.)
There exists a utility called pkfix that can fix this if you happen to have the original ps file, and it has the right comments from dvips.
There is a second utility called pkfix-helper that will try to guess and inject those comments based on the metrics (character sizes) of the fonts. But it can't really match a lot of the symbol fonts that only pull a couple of characters.