Alright, I know people have a lot of mixed feeling...

# arrow-meta

[Nathan Bedell]

Alright, I know people have a lot of mixed feelings about "checked exceptions", but I'm curious, has anyone made/attempted to make a compiler plugin that emulates them in Kotlin? Maybe not necessarily as errors, but as warnings?

I'm just thinking about circumstances in production where an unchecked call to .first() that should have been a .firstOrNull() that snuck past code review leads to an application crash. Since .first() is annotated @Throws I'd at least like to be warned of the possibility of an unhandled exception there that can either be handled, or explicitly suppressed if I can reason to myself it can never happen (Of course, then I'd ideally want to use a NonEmptyList 🙂 -- but the desire to have a plugin like this still stands).

[Nathan Bedell]

And of course, Either is the more functional way of doing this, but here I'm thinking of something in the stdlib or a third-party library.

My current approach is to define a detekt rule that warns against problematic unsafe functions -- but I feel like it would be better if there were a more comprehensive solution.

[raulraja]

Hi @Nathan Bedell we are working on the problem from a different angle

[raulraja]

https://github.com/arrow-kt/arrow-meta/blob/main/plugins/analysis/kotlin-plugin/src/test/kotlin/arrow/meta/plugins/analysis/AnalysisTests.kt

[raulraja]

https://github.com/arrow-kt/arrow-meta/blob/main/plugins/analysis/laws/src/commonMain/kotlin/arrow/analysis/laws/kotlin/Collections.kt#L47

[raulraja]

the second link demonstrates how you define a Law over an existing third party function

[raulraja]

The plugin analyzes the dataflow and lets you know when you are about to open a posibility for an exception to happen based on the expressed constraints

[raulraja]

Arrow Analysis will keep in mind and track @Throws and others, currently is focused in the custom DSL for pre, post and invariants and support third party functions such kotlin.require.

[raulraja]

ETA for first release is end of the year

[pdvrieze]

Kotlin's Result is now allowed to be used outside of coroutines, so is a stdlib compatible alternative to Either (in some cases)

[Nathan Bedell]

@raulraja Will this first release also include compiler-plugin support for HKTs?

[raulraja]

@Nathan Bedell a kinds plugin if its possible with FIR will come later. The first two plugins we are gonna release is the Arrow Analysis plugin and the Arrow Proofs plugin which will support materialization of the with/run automatically for multiple receivers but will most likely remove regular argument injection from the current prototype so it will be even simpler than what’s on the Context tests now. We are looking into supporting multiple receivers when they come out instead of implicit arg injection. The proofs plugin will later expand with automatic derivation for sealed and data classes. Multiple receivers + implicit run/with for N types in the context solves type classes, DI and its simpler to maintain and code than injected args.

[Nathan Bedell]

@raulraja Thanks. That makes sense. I was mainly wondering because I am working on a UI framework similar to Bow Arch yet based off Jetpack Compose, and so due to the current deprecation of kinds in Arrow, I have been making use of KindedJ in my library instead.

Would there be any interest in an interim "arrow-kinds" package making use of KindedJ, including a lot of the old HKT code in pre-0.13 Arrow, refactored to use KindedJ in the interim for people to be able to depend on before support is added back in for kinds (if it is added back in) via a compiler plugin? Perhaps such a library could be released under the "arrow incubator" branding, and not widely advertised.

I'd be happy to do the actual work of digging up the old source code and refactoring it.

I've noticed that there's a PR in the main arrow repo for profunctor optics that perhaps we could incorporate as well. Before I noticed this, I actually started implementing a lot of the same code for myself as part of my project.

[raulraja]

As an org we want to stay away from promoving a kind encoding that is far from ideal and requires things in user code like fix(). Having said that we would like to find an alternative for kinded types as a compiler plugin. If you are interested what I’d like to offer is that we explore together a strategy for a compiler plugin that can support kinds. Something that can be done from the point of view of a compiler plugin is ad-hoc add super types to any type which in this model is making them implment the kind interface. Another thing it can be done is apply implicit conversions between Kind<F, A> and actual F<A>. Also it can be explored how the kind runtime its completely erased and left with the known concrete impls in all call sites that are not polymorphic.

[raulraja]

We could start with some small example as to “what would higher kinded types look like in Kotlin if supported by the compiler” and go from there.

[Nathan Bedell]

@raulraja I'd definitely be interested in that. I think the difficulty for me there would be my lack of understanding of the Kotlin compiler plugin architecture and FIR -- I think I would need that so that I could get a better idea of what sort of things might be possible, and I'm not sure where the best resources for gaining that understanding might be.

[raulraja]

I think regardless of the compiler internals or impl details the first thing would be to come up with a small set of examples of kinds used in declarations and at call sites. Feel free to ping me on DM if you are interested or in #arrow-contributors and we can discuss what that would look like. For example in this new plugin hows does Functor.map look like?