Johan Nordlander

This is in part a simple omission bug (builtin witness `IdentityOpt` isn't properly defined). But more importantly, it also illustrates the limitation of our current approach to type inference for...

Here's where our optional quotes around tuple field names come in handy. Write `(type="tcp", 'actor'=1234)` and the parser will be happy!

Context-sensitive keywords complicate parsing and is therefore generally considered a bad idea. But one can alwas make exceptions on a point-to-point basis if the gains are clear.

I was thinking of writing something like `raise ForClientOnly(exc)` in a method that handles exception `exc` but wants to re-raise it just for any waiting client (the wrapper `ForClientOnly` would...

The error is in the type-checker, but I'm onto it!

Optional is definitely better than Maybe. Perhaps Opt could also be considered, a short name might have benefits. We can probably learn to distinguish this "unboxed" optional type from the...

I agree. And there's actually no need to talk about unboxed types when discussing Maybe/Optional in the documentation, just the fact that constructs like `Maybe[Maybe[X]]` or `list[Maybe[X]]` are disallowed. But...

I think we concluded not to use `None` for holes in a dict, absent function parameters and end-of-iteration (while keeping `None` for implicit function returns). Instead we'll define new global...

I agree with the goals and the problem description, with some comments inlined. -- Johan > On 19 Jun 2023, at 01:08, Kristian Larsson ***@***.***> wrote: > > > I...

The catch is that our type system doesn't yet allow us to express an arbitrary tuple where every component is Hashable. This is something we want, though, not just for...