https://kotlinlang.org logo
Channels
Powered by
#arrow-contributors
  • r

    raulraja

    11/25/2019, 7:42 PM
  • r

    raulraja

    11/25/2019, 7:43 PM
    This mean we’ll be able to include any higher kinded type for third parties and throw away all those wrappers
  • j

    Jannis

    11/25/2019, 7:44 PM
    That will help a bit. But the wrapper is not really the problem, the instance implementations are. Especially default implementations that are not explicitly lazy. I'll do a pass over all instances and override stuff where possible to fix those.
  • r

    raulraja

    11/25/2019, 7:48 PM
    in this case seems like iterator it’s calling itself recursively. If iterator is a new method in Foldable or similar then it may class with the Sequence<A> delegation and call itself recursively, so maybe a problem with the codegen
  • r

    raulraja

    11/25/2019, 7:48 PM
    import arrow.core.extensions.sequencek.functorFilter.filter
  • r

    raulraja

    11/25/2019, 7:48 PM
    We’ve seen this before where it was not calling fix properly and would recursively call itself
  • j

    Jannis

    11/26/2019, 5:08 PM
    https://github.com/arrow-kt/arrow/pull/1816 This should fix the problem for most methods on sequences and hopefully make using them with typeclasses easier.
  • a

    addamsson

    12/07/2019, 11:34 PM
    Hey guys! Does this mean that we won't get typeclasses in 1.4? https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond
  • p

    pakoito

    12/08/2019, 2:33 AM
    yeah it’s just a publicity statement to summarize the improvements over time, the compiler is still the same
    🤣 1
  • p

    pakoito

    12/08/2019, 2:33 AM
    with some improvements here and there
  • r

    raulraja

    12/08/2019, 12:29 PM
    1.4 is IR based. Arrow Meta already has encoded typeclasses with IR
  • r

    raulraja

    12/08/2019, 12:30 PM
    The Type Proofs plugin that I’m working on replaces Type classes and other features and it with will work in IR and ASM. So we have even better ergonomics than those proposed in Keep 87
  • r

    raulraja

    12/08/2019, 12:32 PM
    Type classes are simply intersections by proof:
    Copy code
    @Proof(Extension)
fun String.monoid(): Semigroup<String>
    😍 3
  • r

    raulraja

    12/08/2019, 12:33 PM
    that proyects everything in 
    Semigroup<String>
    and makes it available globally for all values of 
    String
    without the need to import since all type proofs are coherent when resolved as proposed in Keep-87
  • r

    raulraja

    12/08/2019, 12:34 PM
    You can proof other things beside extensions. For example unions:
  • r

    raulraja

    12/08/2019, 12:34 PM
    which enables the syntax:
  • r

    raulraja

    12/08/2019, 12:35 PM
    Copy code
    val stringOrInt: Union2<String, Int> = 0 //ok
val stringOrInt: Union2<String, Int> = "" //ok
val stringOrInt: Union2<String, Int> = 0.0 //not ok because not in the union
  • r

    raulraja

    12/08/2019, 12:35 PM
    or:
    Copy code
    @Proof(Subtyping)
inline fun <reified A> Union4<A, Any?, Any?, Any?>.firstN(): A?
  • r

    raulraja

    12/08/2019, 12:35 PM
    to coerce back to nullable types.
  • r

    raulraja

    12/08/2019, 12:38 PM
    Type Proofs gives us a generalized strategy to create functional preludes a la carte where some of the strategies include synthetic subtyping, extensions, negation, products, derivation etc.
  • r

    raulraja

    12/08/2019, 12:40 PM
    Proofs can be inductive and ploted on a graph to find shortest paths. So if you have A -> B, and B -> C you can have a proof of A to C, and that allows you to merge their APIs just with intersection or even subtyping if that is a type you would have otherwise extended but you can’t because it’s a third party.
  • r

    raulraja

    12/08/2019, 12:41 PM
    In general provides a leaner alternative to things like sealed classes or delegation by construction which is in my opinion very non ergonomic in Kotlin restricted to just interfaces
  • r

    raulraja

    12/08/2019, 12:41 PM
    With unions you can represent Sealed classes with primitives and eliminate the allocation and wrapping
  • r

    raulraja

    12/08/2019, 12:41 PM
    And the same goes for kinds
  • r

    raulraja

    12/08/2019, 12:41 PM
    we no longer have to make any type or wrapper or extend anything
  • r

    raulraja

    12/08/2019, 12:42 PM
    We prove it with an inline erasable runtime that replaces all imposible type cassts that otherwise would have failed after type checkings with proofs.
  • r

    raulraja

    12/08/2019, 12:43 PM
    Proofs draw morphisms from A -> B so they remove the need to explicitly extend or subtype other types in the hierarchy in order to provide ad-hoc behaviors over the values of these types.
  • r

    raulraja

    12/08/2019, 12:48 PM
    Inductive proofs will bring automatic derivation for data classes and sealed classes, unions, etc.
  • r

    raulraja

    12/08/2019, 12:52 PM
    I’m hoping for proofs to be a door into type-level programming for Kotlin and its type system that allows library authors and users to explore and elevate what can be done with the Kotlin type system.
  • a

    addamsson

    12/08/2019, 1:23 PM
    i'm not sure i follow
1...105106107...115Latest