we may be getting new contributors soon 🎉

😄 great work

cheers 😄

Amazing

hi paco thanks for the invite. im not an official card-carrying supporter of anything in particular. that said, elixir is like the same for erlang as typescript for js, almost identical purposes from a 10000 foot view. i wince when i see the Arrow video from Mr. Boss demonstrating "pipe" literally as "pipe", infix is good but that puts the whole stubborn kotlin manifesto in scope, you can only have the sampler platter of null safety, operator overloading, and back-tick keywords,, but when you ask for the dinner it's all sold out

i think that with a tiny macro processing grammar there could be full-on prolog and haskell cmopatible paradigms backed by the more tediously written kotlin arrow

not much more to it than that.

i noticed there is an Option and None, and for my tiny parser combinator i was just scanning the works to date in FP, i have long been a boost template metaprogramming fan, and sometimes paid to be, and so im comfortable with taking templating solutions far beyond the warranty into uncharted waters.

We're not at the point of forking Kotlin mostly because of the maintenance burden. The core of maintainers is small and we don't have a full time R&D team like Elixir originally had

We could use your help in adding constructs to the current compiler, though

you may have seen keep87, and our intention to add typeclasses as first class constructs to the language

and we're desperately looking for someone to contribute to the project of untangling

kotlinc

@jimn shared a file:

i am here with my idiomatic parser combinator. i wouldn't suggest forking kotlin, it's too good, it has a google backing. but i think a new CPP for functional programming is not out of the question

i have a laundry list of gripes with kotlin. they ruled out ternary, they introduced elvis, and at the same time made null-free type system which splits down the middle like king solomon when you start to mix code with other java.

the choice of signalling for streams is using null instead of reusing the Unit/Nil/Void monad.

i think source-to-source compilation is good enough. it hasn't impeded typescript or elixir from production success in the least. im a long-time GWT programmer, i know how to manage the release engineering to make it freindly

i think i've given up talking to the kotlin maintainers about why they did a certain thing or asking if they could expand the glass cielings a bit more. my experience with google backed projects is that if you dont have a google NDA you probably get nowhere

coffeescript actually influenced ECMA 2015 heavily, again a s2s compiler solution. before i undertook such a thing i would want to see all the laundry aired out beside my own tunnel vision perspective. i often look a little too far over the horizon and miss a key blocking factor.

c++ templates were introduced in this way. C++ was a thing, but c-front was written to produce templates as a source-to-source add-on, which turned out to be so important they tucked it into the main compiler designs to reduce build overheads

so i guess the most important question i have is "what is an ideal ebnf syntax for Arrow constructs?"

as shown, i have a few ideas on how to mix down ebnf into kotlin

this was too much for office hours. So on the syntax side, just getting arbitrary operators would already be a potential win

with operator precedence

secondly, receiver functions with multiple parameters. This one is harder

if we want something more syntactic, I guess a better way of expressing typeclass dependencies and extension functions

take a look at this: https://arrow-kt.io/docs/patterns/dependency_injection/

something that makes

fun <F> ApplicativeShow<F, User>.findUserName(id: Kind<F, UserId>): Kind<F, String> = ...

look nicer

i have been using CoroutineContextElements composition rather than DI