Never perform box inference #1090
Conversation
|
For funsies, I also completely removed |
| var x in outer = 42; x | ||
| }; | ||
| val g = test2; | ||
| val g = box test2; |
There was a problem hiding this comment.
RE #878: This is exactly a place where I'd be fine with inferring box :)
(the RHS of a val)
There was a problem hiding this comment.
Yeah, I know. I wanted to see how bad it is if we don't infer boxes at all. This might drive home the point that there is a difference even more (even though it is annoying). I am actually more annoyed by foo(box compareInt).
There was a problem hiding this comment.
Interesting, I always explicitly write the box in map::fromList(..., box compareInt)
|
My hope was that this could make Namer a bit easier in some cases, but I don't see Namer changes, so I'm not sure whether that's true 🤔 |
|
Maybe, I didn't think about it, but just followed the type errors :) |
|
We need to change the docs on the website when merging. |
|
We still need to update the website, for example here https://effekt-lang.org/tour/captures saying -A boxed computation may only be used after unboxing it, which is only permitted when all its captures are in scope.
+A boxed computation may only be used after unboxing it (which happens automatically), which is only permitted when all its captures are in scope. |
This is a quick experiment related to #878 to see how bad things go if we completely disable box inference and only keep unbox inference.