5 ms·

How does this compare to other effect-oriented languages like Koka, Frank, and Eff? I've been doing some work with Koka lately, but I briefly looked into the o

by saityi 5y ago

How does this compare to other effect-oriented languages like Koka, Frank, and Eff? I've been doing some work with Koka lately, but I briefly looked into the other three (including Effekt) and it mostly came down to, 'Koka seems most active in development'[1] and 'Koka had the easiest to use documentation for me'[2], which are both kind of subjective ways of choosing between them rather than an objective comparison. [1] E.g. https://github.com/effekt-lang/effekt https://github.com/effekt-lang/effekt had its last commit back in June; https://github.com/frank-lang/frank https://github.com/frank-lang/frank last commit last year; but https://github.com/koka-lang/koka https://github.com/koka-lang/koka last update was Oct 15. Effekt seems semi-active, at least, compared to Frank. While stability is good, I wouldn't expect it in a language actively being used for research. [2] Comparing https://koka-lang.github.io/koka/doc/book.html https://koka-lang.github.io/koka/doc/book.html and https://effekt-lang.org/docs/ https://effekt-lang.org/docs/ and https://www.eff-lang.org/learn/ https://www.eff-lang.org/learn/

CornCobs 5y ago
Koka is very interesting I must say. It's really cool to see how far they managed to make a functional language look imperative superficially, while being entirely functional under the hood and managing semantics via effects. However, I believe they aren't really able to present a full imperative API to write programs in (or maybe they just haven't fully implemented the needed parts in the stdlib). For example IIRC, the use of mut variables (internal mutability within a function and implicitly handled effect) and the related explicit heap effect don't seem to be able to share functions? And while they seem to work with entire objects the functions for mutations within arrays seemed limited the last time I tried Koka out. And everything being exposed only through the API presented some things were not possible to work around. I believe I was unable to write functions that mutated an array in place. If anyone has had experience with Koka I would love to be proven wrong! That said my initial point still stands - I think its an amazingly cool language and clearly a lot of interesting ideas are in it for sure.
- saityi 5y ago
  So I would say this echoes my experience with it so far -- it is definitely a work in progress! However, I tend to approach Koka as if it were Standard ML with an effect system (up to a point), so the lack of a full imperative API hasn't been felt too much. I am more missing ad-hoc polymorphism than imperative tooling. I am not sure I understand your comment about mut variables; my understanding is there are two types of mutable variables in Koka -- 'local' and 'ref'. 'local' is a locally mutable variable, and 'refs' are globally shareable. A 'ref' can be shared between functions, 'local' is just to give an imperative API using mutable variables. How 'local' works kind of confuses me so I tend to avoid it altogether in favour of local names (i.e. 'val' rather than 'var') and tail recursion (instead of loops with mutation). 'ref' seems quite usable to me and seems to reflect the SML usage of it. I have felt the pain of a lack of an array, but I ported over an Okasaki data structure which has served well for a random-update, sequential data structure. Their data structures in the stdlib just have comments that say 'TODO': https://github.com/koka-lang/koka/blob/master/lib/std/data/map.kk https://github.com/koka-lang/koka/blob/master/lib/std/data/m... that I am hoping are open to pull requests.
  - anfelor 5y ago
    You might be interested in the FBIP versions of Okasakis datastructures in https://github.com/koka-lang/koka/tree/master/test/perf/sets https://github.com/koka-lang/koka/tree/master/test/perf/sets Most of them only have 'insert' and 'lookup', but they are ~10% faster than Okasakis versions. For red-black trees in particular the fastest implementation is https://github.com/koka-lang/koka/blob/master/test/bench/koka/rbtree-fbip.kk https://github.com/koka-lang/koka/blob/master/test/bench/kok...
    - saityi 5y ago
      I'd missed those -- thank you!
  - CornCobs 5y ago
    I'll just hijack this thread to ask a question about effect systems: It seems to me that effects primarily have 2 uses: 1. Provide a controlled form of dynamic scoping (decouple usage and handling - allowing functions to be generic in their effects) 2. Create custom control flow with multiple resumes etc at the effect callsite It feels to me that these are largely orthogonal ideas, but are always conflated in effect systems. Is there a reason for this? Are there examples of one without the other?
- lakecresva 5y ago
  Their section on development tasks mentions fleshing out std and improving array/mutable reference programming, so I think it just hasn't been redone yet. It seems like they spent a lot of development time recently (with great success) working on foundational stuff like perceus/fbip and doing a major version bump, so std is pretty bare.

by saityi 5y ago

CornCobs 5y ago

Koka is very interesting I must say. It's really cool to see how far they managed to make a functional language look imperative superficially, while being entirely functional under the hood and managing semantics via effects. However, I believe they aren't really able to present a full imperative API to write programs in (or maybe they just haven't fully implemented the needed parts in the stdlib). For example IIRC, the use of mut variables (internal mutability within a function and implicitly handled effect) and the related explicit heap effect don't seem to be able to share functions? And while they seem to work with entire objects the functions for mutations within arrays seemed limited the last time I tried Koka out. And everything being exposed only through the API presented some things were not possible to work around. I believe I was unable to write functions that mutated an array in place. If anyone has had experience with Koka I would love to be proven wrong! That said my initial point still stands - I think its an amazingly cool language and clearly a lot of interesting ideas are in it for sure.

saityi 5y ago
So I would say this echoes my experience with it so far -- it is definitely a work in progress! However, I tend to approach Koka as if it were Standard ML with an effect system (up to a point), so the lack of a full imperative API hasn't been felt too much. I am more missing ad-hoc polymorphism than imperative tooling. I am not sure I understand your comment about mut variables; my understanding is there are two types of mutable variables in Koka -- 'local' and 'ref'. 'local' is a locally mutable variable, and 'refs' are globally shareable. A 'ref' can be shared between functions, 'local' is just to give an imperative API using mutable variables. How 'local' works kind of confuses me so I tend to avoid it altogether in favour of local names (i.e. 'val' rather than 'var') and tail recursion (instead of loops with mutation). 'ref' seems quite usable to me and seems to reflect the SML usage of it. I have felt the pain of a lack of an array, but I ported over an Okasaki data structure which has served well for a random-update, sequential data structure. Their data structures in the stdlib just have comments that say 'TODO': https://github.com/koka-lang/koka/blob/master/lib/std/data/map.kk https://github.com/koka-lang/koka/blob/master/lib/std/data/m... that I am hoping are open to pull requests.
- anfelor 5y ago
  You might be interested in the FBIP versions of Okasakis datastructures in https://github.com/koka-lang/koka/tree/master/test/perf/sets https://github.com/koka-lang/koka/tree/master/test/perf/sets Most of them only have 'insert' and 'lookup', but they are ~10% faster than Okasakis versions. For red-black trees in particular the fastest implementation is https://github.com/koka-lang/koka/blob/master/test/bench/koka/rbtree-fbip.kk https://github.com/koka-lang/koka/blob/master/test/bench/kok...
  - saityi 5y ago
    I'd missed those -- thank you!
- CornCobs 5y ago
  I'll just hijack this thread to ask a question about effect systems: It seems to me that effects primarily have 2 uses: 1. Provide a controlled form of dynamic scoping (decouple usage and handling - allowing functions to be generic in their effects) 2. Create custom control flow with multiple resumes etc at the effect callsite It feels to me that these are largely orthogonal ideas, but are always conflated in effect systems. Is there a reason for this? Are there examples of one without the other?
lakecresva 5y ago
Their section on development tasks mentions fleshing out std and improving array/mutable reference programming, so I think it just hasn't been redone yet. It seems like they spent a lot of development time recently (with great success) working on foundational stuff like perceus/fbip and doing a major version bump, so std is pretty bare.