And binding can happen anywhere If you conform to the return type

oh so either

fun foo(a: F<X>, b: F<X>): F<X> {
  val va by a
  val vb by b
  return (a op b)
}

or in

fx { .. }

without the

return

?

Yes but return as keyword is not valid

It would be just or any data type main constructor that lifts values from the environment to that F

oh, so (e.g.)

just (a op b)

or similar. Makes sense

Yes

Anything so I don't have to see

return

is preferable 😄

Since delegation is an actual bind this ensures bindings happen in order and are named so we don't have to make up free variables and untangle them inside out

And since flatMap requires no suspension this runtime should be at least 10 times faster since the current binding reflection trick penalizes users of bind over flatMap

At this point I'd be satisfied if IntelliJ was 10 times faster with Kotlin code

For what is worth IDEA+Kotlin is as decent as it gets. I suffered in Scala for years the lack of good IDEA support for FP but Kotlin support and speed in the editor is IMO better than others

And arrow meta is gonna provide idea support out of the box for all this stuff and much more

We are gonna bring FP to the editor with all it's bells and whistles

Ya on that note I’d love to see better Haskell/Rust support in IDEA too but I’m not holding my breath 😅

These two binds form a logical AND condition. Is there a better way to combine them?

You could use

followedBy

or

flatMap

with

bimap

, or

followedBy

or

flatMap

and `map`/`handleErrorWith`. But I’d say that depends more on style preference

If they are not dependent on order of evaluation you would use Applicative tupled or mapN which are the combinators for independent ops. It would still short-circuit if it finds a Left. Also you can generalize map and fold on a utility operation for all Eithers or even kinds

But all those Monad combinators would work to, they just have more power than what you need there

👏for the new web site ! Interesting idea to propose a navigation by release...

I'm getting a

StackOverflowError

sometimes because my `bind()`'s inside

fx.monad

go pretty deep (too deep, apparently). Are there any simple ways to restructure my code to work around this, or do I just need to rewrite it differently? This usually works fine as a quick way to do validation, but it seems to break down at large scales.

fun <F> MonadError<F, String>.layerGraphIsValid(
    layerGraph: Graph<SealedLayer.MetaLayer>
): Kind<F, Unit> =
    fx.monad {
        layerNamesAreUnique(layerGraph).bind()
        layerGraph.nodes().forEach {
            hasInputs(it).bind()
            inputsAreDeclared(layerGraph, it).bind()
        }
    }

(Increasing the stack size to

512m

works. Not sure if that's the best way though 😛 )

try using

layerGraph.nodes().traverse(...)

instead? (maybe

layerGraph.nodes().k().traverse(...)

)?

@Ryan Benasutti you want

tailrecM

or a Monad that doesn’t SO like IO.

If I use something like

IOMonadError

, how do I adapt that for uses that expect a

Kind<EitherPartialOf<String>, Unit

instead of

Kind<ForIO, Unit>

?

I’m not sure I follow, can you please rephrase?

That method is used in

Either.fx

continuations, so I can't just change the monad it uses without having to change how it's used

use tailrecM then, it’s available for Either

From the docs, it seemed like it was an rx-java integation. Can I use it without rx-java?

Ok I see it now