M main/Main.hs
M main/Repl.hs
M src/Nix/Builtins.hs
M src/Nix/Convert.hs
M src/Nix/Effects.hs
M src/Nix/Effects/Basic.hs
M src/Nix/Eval.hs
M src/Nix/Exec.hs
M src/Nix/Expr/Types.hs
M src/Nix/Json.hs
M src/Nix/Lint.hs
M src/Nix/Normal.hs
M src/Nix/Options/Parser.hs
M src/Nix/Parser.hs
M src/Nix/Scope.hs
M src/Nix/String.hs
M src/Nix/TH.hs
M src/Nix/Thunk/Basic.hs
M src/Nix/Utils.hs
M src/Nix/Value.hs
M src/Nix/Value/Equal.hs
M src/Nix/XML.hs
M tests/EvalTests.hs
M tests/Main.hs
M tests/NixLanguageTests.hs
M tests/ParserTests.hs
M tests/TestCommon.hs
This is needed because of a function like this:
x: y: x + y
This is polymorphic, but over exactly four possibilities:
int -> int
int -> float
float -> int
float -> float
The "type" is really the combination of the four, since we don't yet have a
mechanism like type classes, which could have rendered this as a single type:
(Num a, Num b) => (x :: a): (y :: b): x + y
Going this route will require that we manage an implicit type classes
hierarchy, and perform unification on constraints as well as types. In the
interim, I just lifted the unification algorithm into the LogicT monad, and
use back-tracking search to find all the possible types an expression could
be.
The main problem with using LogicT, however, is that there are many types
it *couldn't* be, and in the case of a unification failure, it not yet clear
what the type should have been. For example:
"foo" + 2
Should the string have been a float or an integer or a path? Or should the
integer have been a string? So for now we report all the possibilities, since
it's not obvious which part of the expression is in error:
hnix: Type error: TypeInferenceErrors
[ UnificationFail (TCon "integer") (TCon "string")
, UnificationFail (TCon "string") (TCon "path")
, UnificationFail (TCon "string") (TCon "float")
, UnificationFail (TCon "string") (TCon "integer")
]
This is a case where enumerating types rather than trying to make them compact
using type classes might actually be an improvement, since the errors here
would have been only slightly less numerous:
string != Num a => a
string != path
integer != string
Clearly a better reporting mechanism is needed to clarify these problems. I
can imagine that in an IDE, there would be a squiggly under both sides of the
expression, each suggesting the type that was expected for that argument under
the assumption that the other argument (the one not be inspected) was the
correct one.
There is still work to be done to render the new "typed frames", and to
convert all the current string based frame into typed frames. This will pave
the way forward to smarter error messages that can be browsed in intelligent
environments like Emacs and the browser.
Anton-Latukha