Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.
What's the status of type inference? Last time I looked into Dhall I was driven off by having to annotate all the polymorphic functions explicitly - but maybe it's just me being used to it in Haskell :slight_smile:
I want to implement it as an editor tool, in dhall-purescript, but I haven't had time to put the research into it. (I would do it a non-standard way.)
Some people were suggesting adding bidirectional type inference, but there were concerns about the maintenance burden for implementations, and the related projects stalled.
Additionally, there are a number of choices being made as the language grows that complicate inference in many ways (overloading operators like .), which I think would make standard bidirectional inference more difficult.
Basically it would be a tool that performs a "fill in holes" functions, for holes that represent inferrable types. But it has to be a highly global search, due to all of the ambiguity. Basically I would propose a monoid that combines information from various usages, plus a couple other features (like refinement, tracing, error handling, backtracking).
As one example of ambiguity, $1.label : $2 can mean:
$1.label : $2
$1 : $3
$2 = $1
$2 = $3 -> $1
All of this type of information needs to be combined in a sensible manner, and it won't be straightforward. Luckily that's the worst case, the rest is more straightforward :wink:
@Nicholas Scheel thanks - so at the end, explicit type arguments are sort of a design decision?