Effect Systems vs. Print Debugging: A Pragmatic Solution
1–10 of 49 posts
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#2I 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!
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#3I 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!
I think the solution is to not have side effects in pure functions really.
At some point you're composing your pure functions and _have_ to call them by some effectful function (otherwise they're never executed or you're doing computations that aren't consumed by anything).
The only sane alternative is to have a debug effectful variant where you turn off these checks. But then why would `stdout` debugging fine, and not say writing to a different stream or file?
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#4Honestly 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.
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#5[dead]
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#6As 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?
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#7I 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!
> 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.
It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of `Debug` effect is already a compilation parameter, it could be generalized to support any sets of implicit effects. Thus you might design a module that has implicit Logger and Database effects in all its functions.
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#8Honestly 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.
The challenge is that the compiler uses the type-and-effect system for many of its tasks, including whole-program optimization and code generation.
If printing- or logging statements have no effect, the compiler might reorder them or even remove them.
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#9Honestly 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.
This is similar to what Haskell has with trace[1]. It pretends to be a pure function (so it doesn't need the IO monad), but prints to stderr.
[1] https://hackage.haskell.org/package/base-4.21.0.0/docs/Debug...
Re: Effect Systems vs. Print Debugging: A Pragmatic Solution
#10I 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!
> 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. It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of…
Singleton pattern isn't really used in functional-effect systems, dependency injection is generally used instead.