| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
- Use TypeLambda instead of PolyType.
- Further harmonize factory operations
|
| | |
|
| |
|
|
|
|
| |
MethodTypes have paramTypes whereas PolyTypes have paramBounds.
We now harmonize by alling both paramInfos, and parameterizing
types that will become common to both.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the added testcase failed because the type of `inv`
was inferred to be `Inv[Any]` instead of `Inv[Int]`. The situation looks
like this:
def inv(cond: Boolean) =
if (cond)
new Inv(1) // : Inv[A] where A >: Int
else
Inv.empty // : Inv[A'] where A' unconstrained
// : Inv[A] | Inv[A']
To get the type of `inv`, we call `harmonizeUnion` which will take the
lub of `Inv[A]` and `Inv[A']`, eventually this mean that we do:
A' <:< A
But since `harmonizeUnion` uses `fluidly`, this does not result in `A'`
getting constrained to be a subtype of `A`, instead we constrain `A` to
the upper bound of `A'`:
Any <:< A
We use `fluidly` to avoid creating OrTypes in `lub`, but it turns out
that there is a less aggressive solution: `lub` calls `mergeIfSuper`
which then calls `isSubTypeWhenFrozen`, if we just make these subtype
calls non-frozen, we can achieve what we want. This is what the new
`lub` parameter `canConstrain` allows.
|
| |\
| |
| | |
Fix type inference for HLists and HMaps
|
| | |
| |
| |
| |
| |
| |
| | |
Turned out hmaps.scala requires the arg alignment to compile.
So we have our first counterexample that we cannot drop this
hack. Now it is made safe in the sense that no constraints get
lost anymore.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Drop the [type T] syntax, and what's associated to make it work.
Motivation: It's an alternative way of doing things for which there seems
to be little need. The implementation was provisional and bitrotted during
the various iterations to introduce higher-kinded types. So in the end the
complxity-cost for language and compiler was not worth the added benefit
that [type T] parameters provide.
Noe that we still accept _named arguments_ [A = T] in expressions; these are useful
for specifying some parameters and letting others be inferred.
|
| |
|
|
|
| |
When printing info about adding to constraints, show the hashes
of the typerstate stack, so that we know where constraints are added.
|
| |
|
|
|
|
|
|
| |
Before adding a constraint, make sure there is no way
the two types are already in a subtype relation.
Adding redundant constraints is problematic because we
might introduce cycles. See i1891.scala for a test.
|
| |
|
