Some questions and Koka's future

[dumblob]

1. What are the goals for type inference? On some places I think I've seen seemingly superfluous type declarations...

2. Do effects pile up syntactically in function declarations?

   1. If yes, how can we tame the enormous clutter (is there any "all-encompassing effect" to just propagate all of them upward the stack)?
   2. If not, is there a way to handle an effect in an outer context/function (be it implicitly or explicitly by some "push it upwards the stack" means)?

   I'm asking because I'm interested among other things in error propagation (imagine optionals).

   Potentially related: Ad-hoc polymorphism #16 (comment)

3. Is casting (implicit and explicit) between types supported?

4. Does Koka support adding own syntactic sugar? Potentially related: Support string interpolation #122 .

   This might help also on other places - e.g. parenthesis around some expressions could become superfluous (if( ... ){ ... } -> if ... { ... }).

5. How is compile time computation supported? Potentially related: Support string interpolation #122 .

6. Does Koka provide any dynamic type evaluation (e.g. "any" type or similar)?

7. How could one do system programming (unsafe stuff, pointers, ...) with Koka?

8. Is there both static (compile-time) and dynamic (runtime) FFI available?

9. Is Koka compiler smart enough to always construct nested or better (instruction-level) parallel loops from "chained" function calls having "map" or similar semantics? Something like https://github.com/zero-functional/zero-functional .

10. Does Koka support ad hoc change/patching/extension of existing structs (e.g. to derive your own string or to add "methods" to some built-in type)?

11. Does Koka support ad hoc change/patching/extension of existing functions (e.g. to shadow an existing function with a redefinition while using the original version inside of this redefinition)?

12. Any benchmarks of numerically intensive computations (i.e. autovectorization, automated SIMD, etc. of matrices etc.)?

13. Does Koka offer any concurrency & parallelism "primitives" (Go-like channels, task-based parallelism, real os-level threading with thread local storage, structured concurrency (e.g. the nursery pattern), locks, etc.)? How efficient is it?

14. Does Koka have any other than in Haskell written compiler (e.g. written in Koka itself to make it self-hosting)?

[anfelor]

I've only followed Koka's development for a while, so take this with a grain of salt. Still here are some answers as I see it:

1. I think there are plans to have Hindley-Milner type inference with overloadings where the correct instantiation can be found from the types of the parameters. So show : a -> String could be overloaded while read : String -> a can't. This is called System O.
2. Yes. i. if you want to just propagate upwards you write the variable e, as for example map does it. ii. I think the closest to an optional is maybe.
3. Not that I know of
4. Not that I know of
5. It is not from what I can tell
6. No. If you would like to know more about how to code without dynamic typing, you might want to learn Haskell. It is much more complicated that Koka imho, but it also has a way bigger community and the basics of the two languages are quite similar.
7. You can call C code using the extern syntax. You can use references as a safer replacement of pointers.
8. To my knowledge it is completely static.
9. This technique is known as fusion. It is not yet supported in Koka, but I could imagine that it will be in the future.
10. Adding fields to an existing struct is not supported (and also impossible unless there is an default value?), but you can certainly write new "methods" for existing types, because they are just functions.
11. Sure, but the two functions need to be in separate modules.
12. Not that I know of. You could add one if you are interested :)
13. Koka has for a long time supported Node.js-style concurrency implemented through effect handlers and libuv. This was broken in a recent update, but will appear again.
14. Not that I know of.

[dumblob]

Thanks a lot for the answers and the reference to System O (I've seen some more recent publications from Martin Odersky, but not this one which explains the extension of Hindley-Milner quite well).

Do you know whether some of the features you answered with not that I know of are on the TODO list or vice versa do you know which are an absolute no go (at least for the time being)?

Regarding (13), just to clarify, does it mean it's all single threaded (i.e. the language runtime scheduler doesn't exist at all or if it does then it's single threaded)?

[anfelor]

On those where I wrote that I don't know: (3) seems hard to integrate with the type system so I don't think that this will happen (4)/(5) seem interesting but don't seem to be priorities (14) A compiler in Koka would certainly nice, but I don't think it will happen soon.

Re (13): Good question! Koka actually supports multiple threads in the runtime system. The async programming paradigm works very well with effects but other modes of concurrency would be possible as well.

[dumblob]

Ok, I think all my questions are answered. Thanks again!