Koka Community Libraries

[TimWhiting]

Hi Everyone, I'd started an organization on Github for Koka community libraries. https://github.com/koka-community

This is intended to be a space where we can share code so others can easily find it, and explore some core APIs prior to integrating into the koka standard library.

I'm tagging a few people who I think might be interested / who have been active here recently, but feel free to add others that you know who have built some libraries in Koka and might want to contribute.

For now, I think we should aim for most libraries to have a MIT license by default so that it is very permissive, with the understanding that the license will change to whatever Koka needs if the library gets integrated into the standard library. (Or we could just have all of them be the same as Koka's license - Apache 2). I'm not super familiar with all the different kinds of licenses, so I'm open to suggestions.

Anyways, let's start a discussion on community guidelines, expectations, important / desired community libraries here, and simultaneously we can start building and contributing. For now I'm just planning to accept anyone as part of the organization, but we should start thinking about how to manage project approvals / reviewers / code owners, and organization member approvals.

Let me know if you are interested!

Discussion on guidelines and expectations continues here: https://github.com/koka-community/community-docs.
General discussions about the community can go in the organization level discussion tab.

@AZMCode, @mccraigmccraig, @anfelor, @woojamon, @swarnpriya, @chtenb, @Ki11erRabbit

[TimWhiting]

I think we should limit it to just a few owners for now, and others can be added as members (which still allows for creating teams and repositories).

[mccraigmccraig]

Count me in @TimWhiting !

On license -, I've spent a lot of time working with clojure in the past decade and Eclipse Public License (clojure itself and many libs) and MIT license (many other libs) are the most popular licenses there... I'm no license expert either, but I've been with a couple of clojure companies through funding and acquisitions with that EPL/MIT ecosystem and never had any lawyers flag any problems from the corporate usage side, so they seem like safe choices (unless ofc they were lazy lawyers 😬)

[TimWhiting]

Thanks! I've added you to the community and added a template repository with the MIT license.

[AZMCode]

I'll do my best to contribute here, but keep in mind I'm still an undergrad that's also holding an internship so I have roughly 2 hours of free time a day 😓.

In any case I'll be working on a small JSON parsing library in the free time I have, and if someone is interested in making a library that implements more utility parser combinators that are niche enough that I wouldn't yet aim to have them in the standard library, but an extra one. I got a couple I could contribute already, and could help work in new ones, but not yet enough to justify a full blown library.

One bigger project I may not have time to do is extending the parser effect the standard library provides to support streaming parsers, which is something I'd love my parser library to have, but I'll need a little more academic knowledge to see that through.

Finally another thing I'd love to do is find some way to make a deserialization framework, à la serde, such that a type can implement one pair of generic ser/de functions, and get access to all supported serialization formats, but again, lots of ideas, little time.

As per licenses, MIT is just fine by me.

I appreciate the help and trust! I'll do my best to help around other projects too whenever I have the time.

[TimWhiting]

Thanks! Yeah, I don't think anyone is writing Koka code as a full time job right now, more just in their spare time. I, myself have some motivation due to working on the compiler for my PhD, but even that is more focused on the research objectives and the Haskell compiler and not writing koka code.

I think we all have probably several parsers written including json :). I have a regex based parser, as well as a (hopefully) performant backtracking parser (not using ctl, but checkpointing the input instead). We should probably create a repository dedicated to trying out different parsers, comparing them for performance and usability / features.

[Ki11erRabbit]

I'll start improving a few of the collections that we wrote. Just let me know where to put them @TimWhiting.
For those that are curious, those collections are: a resizable vector, a hashmap, a hashset, and a min/max heap.

[TimWhiting]

Put them in the std repository for now, under data/. Maybe we should make a collections subfolder. For collections I would not name them generically for now, just call them by their specific names hash-map etc.

[swarnpriya]

Hello Everyone. Thanks for the invite @TimWhiting. I am new to Koka but enjoying every bit of it. Thanks to @TimWhiting for helping me to figure out Koka compiler. I have added some new types and some data structures (will put it in the repo to be decided in future to add it to main repo or not). In future, I will explore more and will have something interesting to share. I am also looking forward to work related to formally verifying the Koka compiler and the type system. I really like the features of the language and am happy to contribute.

[chtenb]

I'd love to contribute. I have been too busy lately to do much with koka, but my interest in the language isn't going anywhere.

[TimWhiting]

Discussion on guidelines and expectations will continue in the community-docs repo: https://github.com/koka-community/community-docs.
General discussions about the community can go in the organization level discussion tab. https://github.com/orgs/koka-community/discussions