4 ms·
In case you need to add logging, you can always close your eyes and use unsafePerformIO anywhere, since from the view of the application, logging is just write-
by mic47 7y ago
In case you need to add logging, you can always close your eyes and use unsafePerformIO anywhere, since from the view of the application, logging is just write-only side-effect.
It's all about how much do you isolate sideeffects from each other. If you go nuts with isolation, you loose flexibility. If you write all your code in IO monad (that means any code can have sideeffect), you are as in other languages where you can do sideeffect anywhere you want.
- h91wka 7y agoOf course you can sneak in Debug.Trace everywhere if you don't compile with -XSafe. But by doing this you basically break your own rules.
- magicalhippo 7y agoThanks for the response. Logging doesn't seem to be an issue then, nice. I'm still curious as to how to introduce variations though. Frequently we find that we have to introduce "if (settings['special_x']) then DoSpecial else DoCommon" deep in the business logic to handle special cases that arise. Assuming the existing function did not depend on the settings, how does one best introduce this dependency on the settings? In our code base we can cheat by effectively having the "settings" dictionary as a global variable, though we try to minimize this obviously. But in a pinch at 4am, that might be enough. How about Haskell, is there a way to "inject" such settings without refactoring all the way to the top?
- h91wka 7y agounsafePerformIO will work. But again, why bother with side effect isolation, if you need to break it to do trivial stuff.
- mbo 7y agoIf you're injecting your settings at the root of your reader monad (which almost all Haskell applications are structured around), how many function calls are you between your monad stack and where you need to thread settings to? 3? Maybe 4? This isn't an issue in practise. It's a 4 line diff. Source: 3 years of pure FP Scala in prod