Closed jbracker closed 6 years ago
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.
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.
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.
I guess I am misunderstanding your question, but can't it stay where it is right now?
I am going to take a try on the direct SVG font file to Haskell translation.
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 theIO
involved explicit, because hiddenIO
is never a good thing. I would suggest:outlMap
. As this actually loads files viaopenFont
(153), we could giveopenFont
andoutlMap
an actualIO
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.IO
is used in line 427 is becausepathFromString
uses IO to print error messages. I think this can be removed and error handling can be done later by returning anEither
,Maybe
orErrorT
. Whatever is preferred.