Tim Whiting

There are a few related issues that I think you are raising all at once. - You don't like how named effects have to be lexically passed - You want...

If I understand right, what you are proposing is something like: ```koka effect file ctl read() : string // Some hypothetical syntax effect config = new file effect data =...

The thing that I don't understand about your proposal is that when you just write `read()` what should be the inferred effect? `file`, `config` or `data`. Does it default to...

In Koka we don't really push effect types down in inference, they are propagated up. So adopting your approach would have to fundamentally change how effect type inference works. Additionally,...

Just ran into this recently as well. I have a branch with a simple fix, but haven't opened it yet, because the API might have to change. Linux reports both...

Positional explicit implicit parameters are not supported except on the dev version of the compiler, but this also fails there, so it is definitely something we need to look into....

@omegametabroccolo The problem is that both `.vector` and `.string` *are* total functions. There is something off with typechecking here (at least from the user's perspective).

Yeah, we should have a normal error here: Change `stream` to `stream`. Anything that should unify with `e` in `|e` needs to be a full effect row - which could...

Yeah, I think it confuses people because if you only have a single effect in a function type, you can omit the row angle brackets in the effect type -...

You can annotate most expressions I think: `expect([] : list) []`. Sometimes you will have to parenthesize it. I think this issue should probably be more about allowing instantiating type...