Direct type class `syntax` over concrete data types #811

raulraja · 2018-04-22T01:20:12Z

The following PR adds a syntax DSL for all data types that arrow exposes type class instances for.

This DSL allows users to not worry about knowing if binding, flatMap etc are in Monad, or what any other combinator they plan on using belongs to a certain type class.

It eliminates the need to explicitly refer to the instances inside the data type companion.

Until now users where forced to do things like:

Option.applicative().map(Option(1), Option(1), Option(1), { (a, b, c) -> a + b + c }) //Option(3)
Option.monad().binding {
  val a = Option(1).bind()
  val b = Option(a + 1).bind()
  a + b
} 
// Option(3)
Option.functor()...
Option.traverse()...

Instead with the syntax DSL most used type classes that the data type provides instances for are bundled as the single this scope of the contained syntax function.
The scope contains all extension functions and static functions that the type classes define and are available to use within the user provided block.

import arrow.instances.*

Option syntax { //`this` is Monad, Applicative, Functor, Traverse, etc...
  binding { ... }
  map(....)
  traverse(...)
}

Either<String>() syntax { //`this` is Monad, Applicative, Functor, Traverse, etc...
  binding { ... }
  map(....)
  traverse(...)
}

The docs contain now instructions for users wanting to provide a similar DSL for their custom data type and it looks like this:

If you defined your own instances over your own data types and wish to use a similar syntax DSL you can do so for both types with a single type argument such as Option:

object OptionContext : OptionMonadErrorInstance, OptionTraverseInstance {
  override fun <A, B> Kind<ForOption, A>.map(f: (A) -> B): Option<B> =
    fix().map(f)
}

infix fun <A> Option.Companion.syntax(f: OptionContext.() -> A): A =
  f(OptionContext)

Or for types that require partial application of some of their type arguments such as Either<L, R> where L needs to be partially applied

class EitherContext<L> : EitherMonadErrorInstance<L>, EitherTraverseInstance<L> {
  override fun <A, B> Kind<EitherPartialOf<L>, A>.map(f: (A) -> B): Either<L, B> =
    fix().map(f)
}

class EitherContextPartiallyApplied<L> {
  infix fun <A> syntax(f: EitherContext<L>.() -> A): A =
    f(EitherContext())
}

fun <L> Either(): EitherContextPartiallyApplied<L> =
  EitherContextPartiallyApplied()

…... }`

…{ ... }`

pakoito · 2018-05-16T02:15:56Z

modules/docs/arrow-docs/docs/docs/patterns/glossary/README.md

+fun <L> Either(): EitherContextPartiallyApplied<L> =
+  EitherContextPartiallyApplied()
+```
+
 If you're defining your own instances and would like for them to be discoverable in their corresponding datatypes' companion object, you can generate it by annotating them as `@instance`, and Arrow's [annotation processor](https://github.com/arrow-kt/arrow#additional-setup) will create the extension functions for you.


This block belongs to the Instances section, before the Syntax one.

pakoito · 2018-05-16T23:39:09Z

modules/core/arrow-instances-core/src/main/kotlin/arrow/instances/either.kt

+}
+
+fun <L> Either(): EitherContextPartiallyApplied<L> =
+  EitherContextPartiallyApplied()


Can we hide the partial implementation?

interface ContextPartiallyApplied<T> { infix fun <A> syntax(f: T.() -> A): A } fun <L> Either() = object: ContextPartiallyApplied<EitherContext<L>> { infix fun <A> syntax(f: EitherContext<L>.() -> A): A = f(EitherContext()) }

pakoito · 2018-05-16T23:41:59Z

To align with the existing documentation I'd rather the DSL objects were suffixed Syntax rather than Context.

pakoito · 2018-05-16T23:46:20Z

Another suggestion I can think of is to move the functions to the companion object of the witness types. That way we can get consistent and unambiguous syntax across types, i.e. ForEither() syntax { } and ForOption() syntax {}.

raulraja · 2018-05-17T13:28:13Z

@pakoito Many types use now syntax that are not kinded and have no witness. For example:

String syntax {
  "a".combine("b")
}
// ab

pakoito · 2018-05-17T14:20:19Z

Here's a snippet that reflects my proposal:

Definition:

object ListKSyntax : Syntax<ListKSyntax>, ListKMonadInstance, ListKTraverseInstance, ListKMonoidKInstance {
  override fun <A, B> Kind<ForListK, A>.map(f: (A) -> B): ListK<B> =
    fix().map(f)
    
  override infix fun <A> syntax (f: ListKSyntax.() -> A): A =
      f(ListKContext)
}
operator fun <A> ForListK.Companion.invoke(): Syntax<ListKSyntax> =
  ListKSyntax

Usage:

ForOption() syntax {
  just(1).sequence(ForListK())
}

For platform types like String or Boolean we will create a new object prefixed with For. This also solves the problem where the platform type Boolean doesn't have a companion object and we need a workaround

arrow/modules/core/arrow-instances-core/src/main/kotlin/arrow/instances/boolean.kt

Lines 22 to 29 in 1020e06

    
           object BooleanInstances { 
        
             fun show(): Show<Boolean> = 
        
               object : BooleanShowInstance {} 
        
             fun eq(): Eq<Boolean> = 
        
               object : BooleanEqInstance {} 
        
           }

ersin-ertan · 2018-05-17T16:46:59Z

Proposal to change syntax to instances

import arrow.instances.*

Option instances { //`this` is Monad, Applicative, Functor, Traverse, etc...
  binding { ... }
  map(....)
  traverse(...)
}

instances plural, when paired with a data type named as a singular ex.Option instances will hopefully be enough to avoid naming clashes with the OOP concept of instantiation(though one may still wrongly assume that a list of instances is being returned)
instances acts like special version of Kotlins scoped function with(...), allowing you to call the functions of the data type's available instances, so instead of writing withAvailableInstancesOf(Option) { ... }, the word instances provides enough context for the representation

pakoito · 2018-05-17T23:16:20Z

What about extensions? ForOption() extensions { ... }

nomisRev · 2018-05-18T14:53:26Z

I'm a little unsure about instances because when I open a ObservableK instances block I'd expect to also have access to effects instances

raulraja · 2018-05-20T17:48:21Z

@nomisRev that has access to the Effect instance.

ForObservableK instances { 
  // `this` is also an `Effect<ForObservableK>`
}

https://github.com/arrow-kt/arrow/pull/811/files#diff-088c779bf125135ce8dbe42b7af6d477R119

nomisRev · 2018-05-20T17:52:28Z

Ah yeah of course. That data type only lives in effects... My bad :D

I meant if I manually add a instance. Or typeclasses/instances defined in Optics, Helios,..

raulraja · 2018-05-20T20:37:05Z

@nomisRev For those cases we are providing instructions to users as part of this PR that tells them how to create the same DSL including their custom instances:
https://github.com/arrow-kt/arrow/pull/811/files#diff-f6d7de9e73be8613678763d3780567e2R152

raulraja · 2018-05-21T15:20:34Z

@pakoito @ersin-ertan @nomisRev
Seems most people I talked to prefer syntax or extensions over instances. also @pakoito proposed prefixing all types with For to work around missing companions for example in Boolean.

Does this look ok to everyone and a fair compromise for now?

ForOption extensions { ... }
ForIO extensions { ... }
ForBoolean extensions { ... }
ForEither<String>() extensions { ... }

nomisRev · 2018-05-21T15:47:30Z

Looks good to me! Also thanks for pointing out the entry in docs 👍

ersin-ertan

Looks good. Clever re-usage of For... too

pakoito

For... extensions gets my green!

* `Const.run(String.monoid) { ... }` + `with(Const, String.monoid()) { ... }` * `Either.run { ... }` + `with(Either) { ... }` * `Eval.run { ... }` + `with(Eval) { ... }` * `Function0.run { ... }` + `with(Function0) { ... }` * `Function1.run { ... }` + `with(Function1) { ... }` * `Id.run { ... }` + `with(Id) { ... }` * `Byte.run { ... }` + `with(Byte) { ... }` * `Double.run { ... }` + `with(Double) { ... }` * `Int.run { ... }` + `with(Int) { ... }` * `Long.run { ... }` + `with(Long) { ... }` * `Short.run { ... }` + `with(Short) { ... }` * `Float.run { ... }` + `with(Float) { ... }` * `Option.run { ... }` + `with(Option) { ... }` * `Either<L>().run { ... }` + `with(Either<L>()) { ... }` * `Const(String.monoid()).run { ... }` + `with(Const(String.monoid())) { ... }` * `Function1().run { ... }` + `with(Function1()) { ... }` * `String.run { ... }` + `with(String) { ... }` * `Try.run { ... }` + `with(Try) { ... }` * `Coproduct(TF, TG).run { ... }` + `with(Coproduct(TF, TG)) { ... }` * `EitherT(MF).run { ... }` + `with(EitherT(MF)) { ... }` * `Ior(SL).run { ... }` + `with(Ior(SL)) { ... }` * `Kleisli(MF).run { ... }` + `with(Kleisli(MF)) { ... }` * `ListK.run { ... }` + `with(ListK) { ... }` * `MapK<Key>().run { ... }` + `with(MapK<Key>()) { ... }` * `NonEmptyList.run { ... }` + `with(NonEmptyList) { ... }` * `OptionT(MF).run { ... }` + `with(OptionT(MF)) { ... }` * `SequenceK.run { ... }` + `with(SequenceK) { ... }` * `SetK.run { ... }` + `with(SetK) { ... }` * `SortedMapK<Key>().run { ... }` + `with(SortedMapK<Key>()) { ... }` * `StateT(ME).run { ... }` + `with(StateT(ME)) { ... }` * `Validated(SL).run { ... }` + `with(Validated(SL)) { ... }` * EitherT type arg name fixes * `WriterT(MF, MW).run { ... }` + `with(WriterT(MF, MW)) { ... }` * mtl: `Const(MA).run { ... }` + `with(Const(MA)) { ... }` * mtl: `Function1().run { ... }` + `with(Function1()) { ... }` * mtl: `Kleisli<F, D, E>(ME).run { ... }` + `with(Kleisli<F, D, E>(ME)) { ... }` * mtl: `ListK.run { ... }` + `with(ListK) { ... }` * mtl: `Option.run { ... }` + `with(Option) { ... }` * mtl: `OptionT(MF).run { ... }` + `with(OptionT(MF)) { ... }` * mtl: `StateT(ME).run { ... }` + `with(StateT(ME)) { ... }` * mtl: `WriterT(MF, MW).run { ... }` + `with(WriterT(MF, MW)) { ... }` * mtl: `DeferredK.run { ... }` + `with(DeferredK) { ... }` * mtl: `FlowableK.run { ... }` + `with(FlowableK) { ... }` * mtl: `ObservableK.run { ... }` + `with(ObservableK) { ... }` * mtl: `IO.run { ... }` + `with(IO) { ... }` * mtl: `Fix(FF).run { ... }` + `with(Fix(FF)) { ... }` * Replaced `run` with infix `syntax` * Ank docs for `Either` and `EitherT` using `syntax` DSL * Ank docs for `NonEmptyList` using `syntax` DSL * Ank docs for `Option` using `syntax` DSL * Ank docs for `Option` and `OptionT` using `syntax` DSL * Ank docs for `SequenceK` using `syntax` DSL * Ank docs for `State` using `syntax` DSL * Ank docs for `StateT` using `syntax` DSL * Ank docs for `Try` using `syntax` DSL * Ank docs for `IO` using `syntax` DSL * Ank docs for `@product` using `syntax` DSL * Ank docs for `DeferredK` using `syntax` DSL * Ank docs for `ObservableK` using `syntax` DSL * Ank docs for DI using `syntax` DSL * Ank docs for Error Handling using `syntax` DSL * Ank docs for Glossary using `syntax` DSL * Ank docs for `MonadError` using `syntax` DSL * Ank docs for `MonadFilter` using `syntax` DSL * Ank docs for `Monoid` using `syntax` DSL * Ank docs for `Order` using `syntax` DSL * Ank docs for `Semigroup` using `syntax` DSL * Ank docs for `Show` using `syntax` DSL * Progress toward refactoring tests * data types syntax in `arrow-free` and related tests * code review * `syntax` -> `extensions` * `For` prefix

raulraja added 19 commits April 22, 2018 02:13

Const.run(String.monoid) { ... } + `with(Const, String.monoid()) { …

c4e0dc5

…... }`

Either.run { ... } + with(Either) { ... }

7baa4fe

Eval.run { ... } + with(Eval) { ... }

3f6b59d

Function0.run { ... } + with(Function0) { ... }

2c8e283

Function1.run { ... } + with(Function1) { ... }

be3f158

Id.run { ... } + with(Id) { ... }

7f4c194

Byte.run { ... } + with(Byte) { ... }

2aa0064

Double.run { ... } + with(Double) { ... }

8e61b8c

Int.run { ... } + with(Int) { ... }

7df14ef

Long.run { ... } + with(Long) { ... }

c1ee30d

Short.run { ... } + with(Short) { ... }

6909d2b

Float.run { ... } + with(Float) { ... }

5d7d990

Option.run { ... } + with(Option) { ... }

8d662e4

Either<L>().run { ... } + with(Either<L>()) { ... }

b70e5b3

Const(String.monoid()).run { ... } + `with(Const(String.monoid())) …

bca778e

…{ ... }`

Function1().run { ... } + with(Function1()) { ... }

deaaf01

String.run { ... } + with(String) { ... }

18e2678

Try.run { ... } + with(Try) { ... }

2717e4f

Coproduct(TF, TG).run { ... } + with(Coproduct(TF, TG)) { ... }

8436ca3

raulraja requested a review from a team April 22, 2018 01:20

raulraja added 7 commits April 22, 2018 03:20

Merge branch 'master' into rr-datatypes-syntax-blocks

b4cda5c

EitherT(MF).run { ... } + with(EitherT(MF)) { ... }

c21898d

Ior(SL).run { ... } + with(Ior(SL)) { ... }

972a9bd

Kleisli(MF).run { ... } + with(Kleisli(MF)) { ... }

8577931

ListK.run { ... } + with(ListK) { ... }

32cc7c8

MapK<Key>().run { ... } + with(MapK<Key>()) { ... }

ac91a6a

NonEmptyList.run { ... } + with(NonEmptyList) { ... }

79c7c2c

raulraja added the work in progress label Apr 22, 2018

raulraja added 2 commits April 22, 2018 13:52

OptionT(MF).run { ... } + with(OptionT(MF)) { ... }

56f22cd

SequenceK.run { ... } + with(SequenceK) { ... }

ea2a784

pakoito reviewed May 16, 2018

View reviewed changes

raulraja added 2 commits May 16, 2018 19:31

data types syntax in arrow-free and related tests

e5592f5

code review

cea442e

raulraja changed the title ~~WIP - Direct type class syntax over concrete data types~~ Direct type class syntax over concrete data types May 16, 2018

raulraja removed the work in progress label May 16, 2018

raulraja requested a review from a team May 16, 2018 18:00

pakoito reviewed May 16, 2018

View reviewed changes

Merge branch 'master' into rr-datatypes-syntax-blocks

ad0686a

Merge branch 'master' into rr-datatypes-syntax-blocks

99d87a7

nomisRev approved these changes May 21, 2018

View reviewed changes

ersin-ertan approved these changes May 21, 2018

View reviewed changes

raulraja and others added 2 commits May 21, 2018 20:30

syntax -> extensions

e74ca93

Merge branch 'master' into rr-datatypes-syntax-blocks

97b257b

pakoito approved these changes May 21, 2018

View reviewed changes

For prefix

1d9563b

raulraja merged commit 84dbd62 into master May 21, 2018

raulraja deleted the rr-datatypes-syntax-blocks branch May 21, 2018 21:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Direct type class `syntax` over concrete data types #811

Direct type class `syntax` over concrete data types #811

raulraja commented Apr 22, 2018 •

edited

Loading

pakoito May 16, 2018

pakoito May 16, 2018 •

edited

Loading

raulraja May 17, 2018

pakoito commented May 16, 2018

pakoito commented May 16, 2018 •

edited

Loading

raulraja commented May 17, 2018

pakoito commented May 17, 2018 •

edited

Loading

ersin-ertan commented May 17, 2018 •

edited

Loading

pakoito commented May 17, 2018

nomisRev commented May 18, 2018 •

edited

Loading

raulraja commented May 20, 2018 •

edited

Loading

nomisRev commented May 20, 2018

raulraja commented May 20, 2018

raulraja commented May 21, 2018 •

edited

Loading

nomisRev commented May 21, 2018

ersin-ertan left a comment •

edited

Loading

pakoito left a comment

Direct type class syntax over concrete data types #811

Direct type class syntax over concrete data types #811

Conversation

raulraja commented Apr 22, 2018 • edited Loading

pakoito May 16, 2018

Choose a reason for hiding this comment

pakoito May 16, 2018 • edited Loading

Choose a reason for hiding this comment

raulraja May 17, 2018

Choose a reason for hiding this comment

pakoito commented May 16, 2018

pakoito commented May 16, 2018 • edited Loading

raulraja commented May 17, 2018

pakoito commented May 17, 2018 • edited Loading

ersin-ertan commented May 17, 2018 • edited Loading

pakoito commented May 17, 2018

nomisRev commented May 18, 2018 • edited Loading

raulraja commented May 20, 2018 • edited Loading

nomisRev commented May 20, 2018

raulraja commented May 20, 2018

raulraja commented May 21, 2018 • edited Loading

nomisRev commented May 21, 2018

ersin-ertan left a comment • edited Loading

Choose a reason for hiding this comment

pakoito left a comment

Choose a reason for hiding this comment

Direct type class `syntax` over concrete data types #811

Direct type class `syntax` over concrete data types #811

raulraja commented Apr 22, 2018 •

edited

Loading

pakoito May 16, 2018 •

edited

Loading

pakoito commented May 16, 2018 •

edited

Loading

pakoito commented May 17, 2018 •

edited

Loading

ersin-ertan commented May 17, 2018 •

edited

Loading

nomisRev commented May 18, 2018 •

edited

Loading

raulraja commented May 20, 2018 •

edited

Loading

raulraja commented May 21, 2018 •

edited

Loading

ersin-ertan left a comment •

edited

Loading