-
Are you have looked at variants, where each
fun. issuspended. by default?
In a typical Kotlin project, nearly all functions become suspended with time. -
What will be the type of the suspended function? Is my intuition that suspended function type hierarchy will be parallel to the functional type hierarchy?
I.e. we will have
SuspendedFunction0[Y]. ... SuspendedFunction1[X,Y], .... etc
and converting SuspendedFunction into Function will be possible only in a specific context,
(where SuspendCapacity is available)?
- It will be good to have an API, which converts between suspended and unsuspended function representations, to allow passing suspended functions as first-citizen objects.
It can be something like
def. unsuspend1[X,Y](f : suspended X => Y): X => SuspendMonad[Y]
(assuming that we have some SuspendMonad)
- In my first understanding, looks, like it will be impossible to pass the suspended function over the collection.map. Is it true?
[
after seen collection.map(x => x.bind) – map should accept suspended function here ?
will collection.map(x => x+1) work ?
]
If yes, potentially this can be solved as in dotty-cps-async, in one of the next ways:
- having a second definition of a map, which accepts suspended functions.
- transform all HOF order functions into functions that accept suspended form only and insert a suspension point into the HOF argument.
This means, that you should transform not only your code, but also all code that can call you functions, or introduce some restrictions. If we want to use suspensions inside the loop – we should change the standard library. It will be interesting to see List or Option. signature with suspension support.
Some problems involving HOF functions is not trivial (for example - fusing filter and map calls for collections, to achieve the same behavior as in a standard library)
- Pushing cps-transform deeper can solve the ‘coloring problem’ for platforms without the support of runtime continuations in a more natural way.