Matthew Lutze
Matthew Lutze
IntelliJ can give hints about the name and type of the parameter that I am typing. We get these a little with autocomplete, but with higher-order functions and long signatures,...
https://github.com/flix/flix/blob/2d6ac85f5690ac02f578854894906cfff80cfd66/main/src/ca/uwaterloo/flix/language/phase/unification/Unification.scala#L251 I assume that this: ```scala case (_, Some(TypeConstructor.Arrow(_))) => Err(getUnderOrOverAppliedError(baseType2, baseType1, type1, type2, renv, loc)) ``` should be this ```scala case (_, Some(TypeConstructor.Arrow(_))) => Err(getUnderOrOverAppliedError(baseType2, baseType1, type2, type1, renv,...
Opacity means nothing in the root namespace
Cases are currently simply `Ident`s. It would be more consistent with our other declarations to give them proper symbols.
E.g. `def f(x: Int32): Int32 \ { ef - ef }` should not be reduced to `def f(x: Int32): Int32 \ { }`, since `ef` is visible. There are two...
```scala @test def testOne(x: Int32): Int32 = x ``` Running this test causes a crash, but we should instead issue a compilation error or test failure
Making this a separate issue so I can mark it as high priority :)
Currently `upcast` requires a pure function. This is fine for the binary effects, but prevents the set effects from upcasting from `{Print}` to `{Print, Throw}`. I think we could implement...
Steps to reproduce: 1. Open clean VSCode project 2. Create Some enum with an `Empty` case 3. See that things compile 4. Reopen VSCode 5. See that there's a name...
The subtyping that we use (KindedVar and UnkindedVar extend Var) is fairly messy: we end up with a lot of pattern matches where we have several `case X => throw...