Matthew Lutze

> I don't think this can work anyway, right? Because of no bound on a. > > @mlutze Thoughts? It's a bug. The bound on `a` is generated automatically. The...

This is in the Monomorph phase. Seems to have something to do with our replacing of tvars with Unit, since the signature type it expects is `Unit -> Unit ->...

Another example: ``` def testLambda03(): (Int, Int) -> Int = (x, y) -> x + y ``` [Playground](https://play.flix.dev/?q=CYUwZgBALiDOUBkCGBbARsJAGAzACgEoAuCPASQDsoAaCSqAiAWgD46qIBeUgD1oE9GrCDwgBqCPyA)

@magnus-madsen Can we reopen this? The lambda case is solved but not the constraint case.

Updated failing case: ``` /// Returns a collection of facts. def getFacts(): #{ Fibonacci(Int32, Int32), Previous(Int32, Int32) } = #{ Fibonacci(0, 1). Fibonacci(1, 1). Previous(1, 0). Previous(2, 1). Previous(3, 2)....

In theory this should check for effect variables too since they could be instantiated to control effects. But effect variables are also very useful with spawn when using regions.

Maybe instead all our type errors should be tentative. "We're not totally sure, but we think there might be a problem with this type"

> > I'm not sure it's a good idea, but we could add an implicit class in `Flix.scala` that wraps `Validation.mapN` and provides a (scala) `map` implementation. That way it's...

IMO we should have both `apply` and `from`, but not two of each.

They serve different purposes. `apply` is for a chain "literal", and `from` is for conversion from another Iterable.