41–49 of 49 posts
As I understand, Flix implements a system to type not only a return type but an Effect too. If that's the case, It's not an overkill solution? and why?
I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed. Either way, extremely well explained both in motivate and implementation!
The other major use case that leaps to mind is "observability"; I want to be able to poke a metric without the function becoming impure, since it is not uncommon for something deep down the call stack to poke a metric and I don't want it to propagate up the stack. You can also make a case for logging that isn't just debug logging. Propagating up a new effect just because some deep function needs to push a log is not…
Honestly a pragmatic solution would be to have printing to stderr (debug print, logs, whatever) not be an "effect". then as an added benefit if its context is elided out in an optimization you know.
It needs to be an effect so the compiler knows how optimizations are permitted to handle it. Otherwise your print statements might appear in totally the wrong order or even not at all. Imagine saying that certain memory stores are allowed to cross a memory barrier operation, you'd completely lose the ability to reason about concurrency around those stores.
It's not just print debugging. It's also logging. Oh, you want/have to add useful/required logging? Good luck refactoring your entire code to thread IO everywhere.
Earlier quoted context omitted.
> Thus you might design a module that has implicit Logger and Database effects in all its functions. Logging does seem like a very similar case to debugging, only that you expect to leave it on in production. On the other hand an implicit Database effect kind of defeat the point of an effect system. I think the key is that Debug and Logger effects don't really affect the rest of the code - if you remove all debug/log…
> Logging does seem like a very similar case to debugging, only that you expect to leave it on in production In a lot of logging systems, debug is one of the common levels of logging. I'm not even convinced that the term "debug" is unambiguous to clearly refer to something that's not a subset logging. Presumably the difference is intended to mean things printed that are unconditionally going to stdout rather than int…
Earlier quoted context omitted.
The other major use case that leaps to mind is "observability"; I want to be able to poke a metric without the function becoming impure, since it is not uncommon for something deep down the call stack to poke a metric and I don't want it to propagate up the stack. You can also make a case for logging that isn't just debug logging. Propagating up a new effect just because some deep function needs to push a log is not…
Are you saying, essentially, that if we split the "I" and the "O" in "IO", then ignore the the "O" in the way described in the article, the resulting program would be "safe-enough" ?
But I think in concept that maybe that's pretty close to the concept. Input from IO is arguably the definition of impure that we care about. But not all forms of Output are necessarily radioactive waste for purity. We might be able in practice to give ourselves a bit more wiggle room on that side without breaking all the benefits of purity, and gain substantial practical utility for a very, very small loss in theory. With some careful thought it's even possible the theory loss could be either "minimized or eliminated" or "strongly characterized and constrained". I don't know enough about the language in question to know what is in it, but a language that had first-class messaging of some sort ought to be able to define a form of output that is "you can send this message to this target any time you want without breaking purity", and the the code for the thing receiving the message could still itself be constrained by the effects system. (You could conceivably go so far as to insist that the resulting "exception handlers" rigidly form a tree that grounds out into code that uses none of these implicit handlers, though my gut says that will probably end up being more trouble than it is worth.)
Earlier quoted context omitted.
> Logging does seem like a very similar case to debugging, only that you expect to leave it on in production In a lot of logging systems, debug is one of the common levels of logging. I'm not even convinced that the term "debug" is unambiguous to clearly refer to something that's not a subset logging. Presumably the difference is intended to mean things printed that are unconditionally going to stdout rather than int…
I was referring to the specific Debug effect described in the post, which only works in debugging builds. This means that the production build cannot have unexpected output from a function with no declared effect.
Earlier quoted context omitted.
Are you saying, essentially, that if we split the "I" and the "O" in "IO", then ignore the the "O" in the way described in the article, the resulting program would be "safe-enough" ?
Hmm, at least in Haskell terms that would not be sufficient, if we define "IO" by the IO type, because some types of O, such as setting the value of IORefs, is definitely something that could be witnessed elsewhere depending on the flow of the IORef in question. But I think in concept that maybe that's pretty close to the concept. Input from IO is arguably the definition of impure that we care about. But not all form…
https://hackage-content.haskell.org/package/bluefin-0.0.17.1...