Skip to content

Consider adding LazyIO and friends #525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sobolevn opened this issue Jul 31, 2020 · 4 comments
Open

Consider adding LazyIO and friends #525

sobolevn opened this issue Jul 31, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@sobolevn
Copy link
Member

The thing about IO in multiple languages / libraries is that it is lazy.

Our IO is not lazy by design. It is done, so Python developers can use it like so: impure(print)(1) # prints "1"
But, we also need to think about other problems as well:

  1. Retries, with proper lazy IO one can retry an operation as many times as one wishes: p = impure_lazy(print)(1); p(); p() # prints "1" twice
  2. Semantical identity to Future, currently it is not similar to regular IO, because Futures are lazy: they don't run until they are executed properly
  3. New users will find the similar data-type they already know from other languages / libraries
@sobolevn sobolevn added the enhancement New feature or request label Jul 31, 2020
@sobolevn
Copy link
Member Author

sobolevn commented Jul 31, 2020

LazyIO(x) is basically just IO(lambda: x).

But, when talking about composition, we need to give it a helping hand:

Lazy = Callable[[], _ValueType]

class LazyIO(...):
    inner_value: Lazy[IO[_ValueType]]

    def __init__(self, inner_value: Lazy[IO[_ValueType]]) -> None: ...

    def __call__(self) -> IO[_ValueType]: ...

    def map(self, function: Callable[[_ValueType], _NewValueType]) -> LazyIO[_NewValueType]:  ...

def lazy(inner_value: _ValueType) -> Lazy[_ValueType]: ...

def lazy_impure(function: Callable[..., _ValueType]) -> Callable[..., LazyIO[_ValueType]: ...

It is much better than working with IO(lambda: x)

@thepabloaguilar
Copy link
Member

This can be useful to create something like lazy_cond that accepts lazy objects as the inner values:

def example(arg: str) -> Result[int, str]:
    return lazy_cond(Result, arg.isnumeric(), Lazy(int), 'Is not a number')

assert example('42') == Success(42)
assert example('string') == Failure('string')

Today is impossible to make something similar and simple

@sobolevn
Copy link
Member Author

Well, I was wrong. LazyIO is not IO(lambda: x) it is lambda: IO(x)

@sobolevn sobolevn mentioned this issue Jan 27, 2021
4 tasks
@efagerberg
Copy link

efagerberg commented Apr 25, 2021

I know the documentation mentions IOs are not lazy because it would be more familiar to existing python developers and help with using the impure decorator. However I am skeptical that this is as useful in practice. Most people using this library I assume are starting with some traditional understanding of the IO monad.

Taking my personal experience as an example, I learned explicitly that the IO monad is supposed to be something like a grenade that the caller pulls the pin from when they are ready, and not just a wrapper to tell the user the data came from some nondeterministic world. This common form of IO in my reading has also been used to build on the ideas of functional composition and equational reasoning.

In my example I started in earnest with reading https://github.com/MostlyAdequate/mostly-adequate-guide, maybe my experience is not representative of everyone's. I am just not as sure the value of a simple IO container is compared to the traditional definition. The traditional definition helps more to represent a value is non deterministic but still returns a deterministic value, an IO with some function inside of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

3 participants