koka VS linear-base

This post by the Koka-author is an update about what's currently being worked on: https://github.com/koka-lang/koka/discussions/339

Some programming language like JS, use path-based imports, that's not good for making a stabel API.

See https://api-extractor.com/pages/setup/configure_rollup/#:~:text=(The%20API%20Extractor,with%20that%20effort.)

And https://github.com/koka-lang/koka/issues/31#issuecomment-1482200826

It also offers a great Inversion of Control mechanism where everything is customisable, and, unlike Capability Objects, AESs also offer compatibility with type inference (you can pass functions doing IO to map, and it Just Works(TM)) and first-class control over stack frames (because really a continuation function is just some stack frames, which you can manually move to the heap if you want a closure; which means async is an effect!). It also is composable in ways Monads are not.

Koka and other languages implementing Algebraic Effect Systems make everything a user-defined case of coroutines: async is just another effect/Monadic type. Zig does something similar by having first class stack frames, making all function calls possibly asynchronous.

Super interesting, there is a proposal to add this to JavaScript and several languages that use this, unison, koka & eff. I had no idea this was even a thing!

Koka, already cited in this thread, early 2010s. Koka's first claim to fame was a usable effect system (at the type were, basically, effect systems were not usable in practice; in fact few languages have managed to do as well as Koka since). Now its author is working on cool implementation strategies for functional languages as well.

I'm a software engineer with 3 years of professional experience. I worked for 2 years at Microsoft on Azure Compute and now work at Google, working on improving Google search. I am the sole maintainer of the popular open-source library microlens with 80k downloads. I've also contributed to the Koka programming language developed at Microsoft Research.

By implementing all of those optimizations in the Koka programming language, they achieved GC overhead much less and execution time faster than the other languages including OCaml, Haskell, and even C++ in several algorithms and data structures that frequently keep common sub-structures of them, such as red-black trees. For more information, see the latest version of the paper.

lol no Data.Dough.Destination

Thanks for your interest in linear types. The sort of overarching answer is that the Covid crisis has put a serious wrench in our plans. There has been very little progress on the implementation in the past 2 years, I'm afraid. I hope to slowly pick up the pace again this year. But I make no promise as to specific plans just yet. When we have more visibility, we will publish a roadmap. This is not to say that nothing has happened at all: linear-base is getting a pretty significant release any day now, David Feuer (no affiliated with Tweag) has created linear-generics, an implementation of Generic which is compatible with linear types (there is a surprisingly subtle issue with Generic1, in particular, that I don't understand very well, so won't try to explain), we co-wrote two academic articles as well.

See here for a linear quicksort implementation.

Handle is defined in terms of UnsafeResource (in linear-base). This is where the linearity checking "stops". If you pattern match an UnsafeResource then you have to make sure that you correctly close/free it. Luckily, this only has to be implemented once in an internal module and is not exported in the public interface.

The optics sublibrary is not very developed yet. Because our arrays, which are one of the principal use-case, require a special kind of lens which we haven't managed to produce without too much code duplication yet. The design space is discussed in this issue.

So to write a function f :: a %1 -> () you have to traverse the whole datatype a, see the Data.Unrestricted.Internal.Consumable and Data.Unrestricted.Internal.Instances, which introduces a type class consumable which implements exactly this functionality.

Trying to run empty Ur shouldn't typecheck, because the Ur constructor is not linear. This seems to be an idiom used in other places of linear-base.