[DISCUSSION] Exact Core 0.0.1 #8

ILIYANGERMANOV · 2023-05-06T21:03:36Z

Thank you @ustits for the awesome idea to drop the entire builder and just use a simple Raise<E>.f(A) -> R function!
Based on our discussions in #4 , #6 and #7. This is how I imagine the entire Exact Core to look like.

core = just providing the capabilities to build Exacts and Refined types
common = a collection of built-in Refined types like PositiveInt, NotBlankTrimmedString, etc

This PR is raised for discussion purposes and if we happen to like the ideas in it - we can merge it and build on top of it.
As always I'm more than open to suggestions and any changes - big or small! 👍

Can't wait to use our small Arrow Exact library in my personal projects! 🚀

ILIYANGERMANOV · 2023-05-06T21:08:19Z

Demo

@JvmInline
value class NotBlankString private constructor(
  override val value: String
) : Refined<String> {
  companion object : Exact<String, NotBlankString> by exact({
    ensure(it.isNotBlank()) { ExactError("Cannot be blank.") }
    NotBlankString(it)
  })
}

@JvmInline
value class NotBlankTrimmedString private constructor(
  override val value: String
) : Refined<String> {
  companion object : Exact<String, NotBlankTrimmedString> by exact({ raw ->
    val notBlank = NotBlankString.from(raw).bind()
    NotBlankTrimmedString(notBlank.value.trim())
  })
}

sealed interface UsernameError {
  object Invalid : UsernameError
  data class Offensive(val username: String) : UsernameError
}

@JvmInline
value class Username private constructor(
  override val value: String
) : Refined<String> {
  companion object : ExactEither<UsernameError, String, Username> by exactEither({ rawUsername ->
    val username = NotBlankTrimmedString.from(rawUsername)
      .mapLeft { UsernameError.Invalid }.bind().value
    ensure(username.length < 100) { UsernameError.Invalid }
    ensure(username !in listOf("offensive")) { UsernameError.Offensive(username) }
    Username(username)
  })
}

@JvmInline
value class PositiveInt private constructor(
  override val value: Int
) : Refined<Int> {
  companion object : Exact<Int, PositiveInt> by exact({
    ensure(it > 0) { ExactError("Must be positive.") }
    PositiveInt(it)
  })
}

I don't know about you but creating Exact/Refined types is fun! I think we're going in the right direction :) I'm wondering if there's more utility that we'd like to add?

ILIYANGERMANOV · 2023-05-06T21:10:59Z

src/commonMain/kotlin/arrow.exact/Exact.kt

  }
+
+  // TODO: What are your thoughts about this?
+  operator fun invoke(value: A): R = fromOrThrow(value)


This is a bit controversial. What do you think?
My opinion is that there are many cases where you're sure that something matches the constraints and going through the hassle of dealing with an Either is unnecessary.

// here I'm certain that positive + positive is always a positive fun plus(x: PositiveInt, y: PositiveInt): PositiveInt = PositiveInt(x.value + y.value) fun plusUgly(x: PositiveInt, y: PositiveInt): PositiveInt = PositiveInt.fromOrThrow(x.value + y.value)

I personally think orThrow is concise enough it's worth the readability. Kotlin favours explicitness in a lot of areas, and this seems a place that is a good trade-off for it as well.

Yes, that's true @nomisRev . IMO, it just becomes too verbose, distracting and not right making the possibility of throwing an exception for cases where that's obviously impossible like:

val hello = NotBlankTrimmedString.fromOrThrow("Hello") val world = NotBlankTrimmedString.fromOrThrow("wold!") val helloWorld = NotBlankTrimmedString.fromOrThrow(hello.value + " " + world.value)

Personal opinion, the above is too much noise and I prefer the below:

val hello = NotBlankTrimmedString("Hello") val world = NotBlankTrimmedString("wold!") val helloWorld = NotBlankTrimmedString(hello.value + " " + world.value)

Note these two are artificial examples but in practice we have many places where we're certain that a constraint won't be violated, in my personal projects I reserve the operator fun invoke(value: A): R = fromOrThrow(value) for such cases.

When using for example PositiveInt(x + y) instead of PositiveInt.fromOrThrow(x + y) we show our readers that we're certain that in the first case x + y will always be positive but in the 2nd we direct their attention to knowing that it's not always the case.

I suggest leaving it for discussion and re-visiting before releasing the library.

src/commonMain/kotlin/arrow.exact/Exact.kt

ustitc · 2023-05-06T22:11:16Z

Looks fantastic 🚀

I also want to explore these topics

custom ensure for Exact like

ensure(it, NotBlankString) {
  UsernameError.Invalid
}

It will make chaining of Exacts easier

Exacts composition. For example it would be cool to have

class UserName {
  companion object : NotBlankString and StringWithLengthLt(16)
}

It will also give us room to ship predefined Arrow Exacts and for communities to build their own and share. I had the same idea in krefty with Predicates but predicate alone turned out to be useless without type conversion and errors

Can we make a declaration of Exact/ExactEither more compact?

Will make one more round later but already looks as a good candidate for 0.0.1

ILIYANGERMANOV · 2023-05-06T22:33:17Z

Looks fantastic 🚀

I also want to explore these topics

custom ensure for Exact like
ensure(it, NotBlankString) {
  UsernameError.Invalid
}
It will make chaining of Exacts easier

Exacts composition. For example it would be cool to have
class UserName {
  companion object : NotBlankString and StringWithLengthLt(16)
}
It will also give us room to ship predefined Arrow Exacts and for communities to build their own and share. I had the same idea in krefty with Predicates but predicate alone turned out to be useless without type conversion and errors

Can we make a declaration of Exact/ExactEither more compact?

Will make one more round later but already looks as a good candidate for 0.0.1

+1 for all topics! Let's explore them 🚀

Looks doable and awesome for predicates! The downside is that with this type of ensure we lose all transformations - e.g. won't work with NotBlankTrimmedString.

ensure(it, NotBlankString) { UsernameError.Invalid }

Yes, we need a good way of composing Exacts w/o losing the transformations (type conversions)

Feel free to suggest designs on it.

I haven't explored much but will gladly welcome any suggestions for reducing the boilerplate! So far, that's the best I can get to compile 😀

@ustits I'm wondering should we merge this PR so we can build 1) and 2) on top of it? Alternatively, each of us can play on a different versions of Exact and in the end we'll pick the best from both variants. I'm okay with both approaches 👍

src/commonMain/kotlin/arrow.exact/Exact.kt

src/commonMain/kotlin/arrow.exact/ExactDsl.kt

nomisRev · 2023-05-08T06:00:34Z

src/commonMain/kotlin/arrow.exact/demo/Demo.kt

+import kotlin.jvm.JvmInline
+import kotlin.random.Random
+
+// TODO: We need a lint check telling people to make their constructors private


Should we make an issue to make a small detekt integration module for this?

nomisRev

All looks great 👏 👏 Great discussion and improvements overall ☺️

Looks doable and awesome for predicates! The downside is that with this type of ensure we lose all transformations - e.g. won't work with NotBlankTrimmedString.
ensure(it, NotBlankString) { UsernameError.Invalid }

Hmm, I'm not sure about that.. We could have NotBlankString as a sort of filter map. So something like.

import arrow.core.Either
import arrow.core.raise.Raise
import arrow.core.raise.either
import arrow.core.raise.ensureNotNull

fun interface FilterMap<A : Any, B : Any> {
  operator fun invoke(a: A): B?
}

fun <E, A : Any, B : Any> Raise<E>.ensure(
  a: A,
  filterMap: FilterMap<A, B>,
  error: (A) -> E
): B {
  val b = filterMap(a)
  return ensureNotNull(b) { error(a) }
}

val NotBlankString: FilterMap<String, String> =
  FilterMap { it.ifBlank { null } }

object Invalid

val x: Either<Invalid, String> = either {
  ensure("hello", NotBlankString) { Invalid }
}

So by constraining A and B to non-null we can avoid needing Option, and we can use null as a false signal for the predicate. I choose FilterMap as a name here, but that's perhaps not a great name. MapNotNull might be more in line with Kotlin Std. It offers a similar pattern for Iterable.

I really like the idea of being able to compose, expose/share predicates, or refinements like this as @ustits did in krefty.

We can probably remove Refined, or replace it with a typealias Refined<A> = Either<ExactError, A> and see how it plays out.

I am okay merging this PR, and doing follow ups. That would be easier for discussing further I think. Again really awesome @ustits and @ILIYANGERMANOV ❤️

This week I am going to setup all the configuration for publishing this library, so we can publish 0.0.1 whenever we think is a good moment 🥳

ustitc · 2023-05-08T06:56:09Z

@nomisRev

I really like the idea of being able to compose, expose/share predicates, or refinements like this as @ustits did in krefty.

We can borrow some ideas from Clojure community, they had much more time refining them in specs https://clojure.org/guides/spec#_composing_predicates

So actually if I think about this.. Is Refined not the same as Either<ExactError, A>? 🤔 And do we not get all required functions through that?
We can probably remove Refined, or replace it with a typealias Refined = Either<ExactError, A> and see how it plays out.

Came up with the same thought after changing an api of krefty this week, Refinement (renamed it from Refined) became a monad with almost the same functionality as Either

refine(NotBlank(), "Krefty")
    .map { NotBlankString(it) }
    .flatMap { refine(UserNamePredicate(), it) }

This week I am going to setup all the configuration for publishing this library, so we can publish 0.0.1 whenever we think is a good moment 🥳

Thanks! 🚀

ILIYANGERMANOV · 2023-05-08T08:41:15Z

Thank you both @ustits and @nomisRev! We're making awesome progress on this library! You suggested great points, let's explore them 🚀 I merged this PR for the sake of easier discussions and building on top of it.

Changes:

Refined<A> removed

TODO:

Composing Exacts
Ensure for Exact ([DISCUSSION] Exact Core 0.0.1 #8 (review))

nomisRev · 2023-05-08T09:04:29Z

Came up with the same thought after changing an api of krefty this week, Refinement (renamed it from Refined) became a monad with almost the same functionality as Either

Is there a commit you can share? Would love to see how you implemented this?

We can borrow some ideas from Clojure community, they had much more time refining them in specs https://clojure.org/guides/spec#_composing_predicates

Interesting, I like Clojure and hadn't thought of this for inspiration. I've always thought of Scala refined libraries, but the Clojure docs you shared have a lot of great ideas!

ustitc · 2023-05-08T10:00:11Z

@nomisRev you can check it by this commit where I added map and flatMap ustitc/krefty@ac67a74#diff-78a62f4e2244be79cf81a394e044b8971ac9ddd195afd6add4ef31d4c3e2f830

Also has a local commit which introduces filter so Refinement can be used like this

refine("Krefty")
    .filter(NotBlank())
    .filter { it.length > 3 }
    .map { NotBlankString(it) }
    .flatMap { refine(UserNamePredicate(), it) }

nomisRev · 2023-05-08T11:02:19Z

Looking at this I'd love to have some Raise based Refinement DSL. Looking at what you've shown above it could probably be made available through a DSL that looks something like this.

val Either<NoExact, NotBlankString> =
  refine("Krefty") {
    notBlank() // refine(NotBlank)
    ensure(it.length > 3)
    refine(UserNamePredicate)
    NotBlankString(it)
  } // getOrElse, getOrNull, bind, etc.

refine methods would also return a val x: String in this case, but since it's refinements you can just go top-down and we an use Kotlin Contracts as well within the DSL. Although Kotlin Contracts are still limited, I expect a bit more powerful support in K2 and hopefully more powerful during Kotlin 2.x

ILIYANGERMANOV · 2023-05-08T11:04:04Z

Looking at this I'd love to have some Raise based Refinement DSL. Looking at what you've shown above it could probably be made available through a DSL that looks something like this.
refine("Krefty") {
  notBlank() // refine(NotBlank)
  ensure(it.length > 3)
  refine(UserNamePredicate)
  NotBlankString(it)
}

@nomisRev, that looks awesome! +1

nomisRev · 2023-05-08T11:07:55Z

I guess this is already close to what we have with exact, but perhaps we can do something like.

interface ExactScope<A> : Raise<ExactError> {
  val raw: A
  
  fun refine(refine: FilterMap<A>): A
  
  // ...
}

val NotBlank: FilterMap<String> =
  FilterMap { it.ifBlank { null } }

fun ExactScope<String>.notBlank(): String = refine(NotBlank)

PS: I don't like the FilterMap name 😂

ILIYANGERMANOV · 2023-05-08T11:30:39Z

I guess this is already close to what we have with exact, but perhaps we can do something like.

interface ExactScope<A> : Raise<ExactError> {
  val raw: A
  
  fun refine(refine: FilterMap<A>): A
  
  // ...
}

val NotBlank: FilterMap<String> =
  FilterMap { it.ifBlank { null } }

fun ExactScope<String>.notBlank(): String = refine(NotBlank)

PS: I don't like the FilterMap name joy

Awesome! @nomisRev can you submit a PR with it? I like it a lot!
Name suggestion: FilterMap -> Refinement (it's basically a filter + map = mapNotNull, as you said and named it but IMO we'll confuse fewer people if we call it Refinement<A> and provide KDoc. At the end of the day, we'll spam refine(XXX) in the ExactScope.

I'm excited to add arrow-exact-0.0.x to Ivy Wallet 🚀 , IMO, if we can do the improvements discussed, it'll become usable and after testing it internally we'll gather more ideas and feedback.

nomisRev · 2023-05-08T12:11:15Z

I can do a PR for that this week.

ILIYANGERMANOV added 11 commits May 5, 2023 17:38

Draft ExactBuilderDsl

f9ad9b9

Add DSL marker

5690e17

Add tests and refactor

8acee25

Rename file

7544e44

Fix the unit tests

6e84b5f

Fix the unit tests setup

65b5c89

WIP: Re-worked Exact core

50aa234

Implement Exact core (no extensions)

9cf25cc

Fix the core

e5211f5

Cleanup and shape

c78e69d

Exact core 0.0.1

8c620fd

ILIYANGERMANOV mentioned this pull request May 6, 2023

[DRAFT] Exact Builder Dsl #7

Closed

ILIYANGERMANOV requested review from ustitc and nomisRev May 6, 2023 21:05

ILIYANGERMANOV commented May 6, 2023

View reviewed changes

ustitc reviewed May 6, 2023

View reviewed changes

src/commonMain/kotlin/arrow.exact/Exact.kt Outdated Show resolved Hide resolved

nomisRev reviewed May 8, 2023

View reviewed changes

src/commonMain/kotlin/arrow.exact/Exact.kt Show resolved Hide resolved

nomisRev reviewed May 8, 2023

View reviewed changes

src/commonMain/kotlin/arrow.exact/ExactDsl.kt Outdated Show resolved Hide resolved

nomisRev reviewed May 8, 2023

View reviewed changes

nomisRev approved these changes May 8, 2023

View reviewed changes

ustitc approved these changes May 8, 2023

View reviewed changes

Remove Refined<A>

0334c72

ILIYANGERMANOV merged commit 371c5f9 into arrow-kt:main May 8, 2023

nomisRev mentioned this pull request May 9, 2023

Setup publishing, dokka & knit #11

Merged

ILIYANGERMANOV mentioned this pull request May 14, 2023

Exact DSL draft #6

Merged

renovate bot mentioned this pull request Feb 29, 2024

Update all dependencies #32

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DISCUSSION] Exact Core 0.0.1 #8

[DISCUSSION] Exact Core 0.0.1 #8

ILIYANGERMANOV commented May 6, 2023 •

edited

Loading

ILIYANGERMANOV commented May 6, 2023

ILIYANGERMANOV May 6, 2023 •

edited

Loading

nomisRev May 8, 2023

ILIYANGERMANOV May 8, 2023

ustitc commented May 6, 2023 •

edited

Loading

ILIYANGERMANOV commented May 6, 2023

nomisRev May 8, 2023

nomisRev left a comment

ustitc commented May 8, 2023 •

edited

Loading

ILIYANGERMANOV commented May 8, 2023

nomisRev commented May 8, 2023

ustitc commented May 8, 2023

nomisRev commented May 8, 2023 •

edited

Loading

ILIYANGERMANOV commented May 8, 2023

nomisRev commented May 8, 2023 •

edited

Loading

ILIYANGERMANOV commented May 8, 2023 •

edited

Loading

nomisRev commented May 8, 2023

[DISCUSSION] Exact Core 0.0.1 #8

[DISCUSSION] Exact Core 0.0.1 #8

Conversation

ILIYANGERMANOV commented May 6, 2023 • edited Loading

ILIYANGERMANOV commented May 6, 2023

ILIYANGERMANOV May 6, 2023 • edited Loading

Choose a reason for hiding this comment

nomisRev May 8, 2023

Choose a reason for hiding this comment

ILIYANGERMANOV May 8, 2023

Choose a reason for hiding this comment

ustitc commented May 6, 2023 • edited Loading

ILIYANGERMANOV commented May 6, 2023

nomisRev May 8, 2023

Choose a reason for hiding this comment

nomisRev left a comment

Choose a reason for hiding this comment

ustitc commented May 8, 2023 • edited Loading

ILIYANGERMANOV commented May 8, 2023

nomisRev commented May 8, 2023

ustitc commented May 8, 2023

nomisRev commented May 8, 2023 • edited Loading

ILIYANGERMANOV commented May 8, 2023

nomisRev commented May 8, 2023 • edited Loading

ILIYANGERMANOV commented May 8, 2023 • edited Loading

nomisRev commented May 8, 2023

ILIYANGERMANOV commented May 6, 2023 •

edited

Loading

ILIYANGERMANOV May 6, 2023 •

edited

Loading

ustitc commented May 6, 2023 •

edited

Loading

ustitc commented May 8, 2023 •

edited

Loading

nomisRev commented May 8, 2023 •

edited

Loading

nomisRev commented May 8, 2023 •

edited

Loading

ILIYANGERMANOV commented May 8, 2023 •

edited

Loading