Remove unsafePerformIO

[jbracker]

I noticed that there are some hidden unsafePerformIO calls in ReadFont.hs on line 153, 336 and 427. I guess these are there to make it seem as if everything was still pure like in the rest of diagrams. But I would suggest to make the IO involved explicit, because hidden IO is never a good thing. I would suggest:

• Line 336 only uses IO to get the path in calls to outlMap. As this actually loads files via openFont (153), we could give openFont and outlMap an actual IO type. The user would only have to deal with that when she actually wants to load a font. That does not have to be a pure action and a loaded font can be handed in as needed later on.
• The only reason IO is used in line 427 is because pathFromString uses IO to print error messages. I think this can be removed and error handling can be done later by returning an Either, Maybe or ErrorT. Whatever is preferred.

[tkvogt]

You are right. It is maybe more natural to use IO here. What worries me much more is that the speed of SVGFonts is so bad. I would like to try out to replace xml and parsec with attoparsec. I try to do this on the weekend. Then pathFromString changes anyway. But at least one unsafePerformIO is necessary somewhere if we want to avoid the IO-Monad-Virus to infect diagrams completely. I am more in the camp that thinks unsafeperformIO should be called IKnowWhatIDoIO. Another trick would be to translate the svg files into source files during installation.Or we could invent a ReadOnlyIO Monad that allows only read only operations and extend to the operating system level the guarantee of this.

[jbracker]

I don't see why making reading a font file an IO operation would infest diagrams with the IO monad. Reading a font file is an input operation, as writing things to the screen with cairo or to an SVG file are output operation. The IO monad is there to mark the gateway of leaving the pure world. So why would it be bad to use it as intended and widly agreed to mark an input operation when loading a font. Using the loaded font afterwards within diagrams would not influence the pure world of diagrams.

I like the idea translating the SVG font into a haskell source. That way the need of IO would also go away.

[tkvogt]

But where to put openFont? I must admit I don't know. That's why used unsafePerformIO. Translating a font file to a source file is an interesting experiment.

[jbracker]

I guess I am misunderstanding your question, but can't it stay where it is right now?

[jbracker]

I am going to take a try on the direct SVG font file to Haskell translation.