type inference with lambdas doesn't work (requires explicit types)

[timotheecour]

in D this works:

auto testCallFun(alias fun)() { return fun(0); }
void main(){
  import std.stdio:writeln;
  writeln(testCallFun!(x=>x*2)());
}

in nim apparently this doesn't unless explicit types are provided:

import future
proc testCallFun[T](fun: T): auto = result = fun(0)
proc main() =
  # not ok: Error: invalid type: 'GenericParam' in this context: 'proc (fun: proc (x: GenericParam): untyped){.noSideEffect, gcsafe, locks: <unknown>.}' for proc
  echo testCallFun(x => x * 2)

  #ok with explicit type:
  echo testCallFun((x:int) => x * 2)

This pattern is heavily used and quite useful for generic code.

• Is there any fundamental reason why this can't work in nim?

• if not, is that on the roadmap?

potentially related

• Problem with generic lambdas #3127 Problem with generic lambdas Problem with generic lambdas #3127

[Araq]

Not on the roadmap as I can't figure out how to infer this type myself. Use a template instead, maybe.

This pattern is heavily used and quite useful for generic code.

We managed so far to do without it. Btw "generic" is not a synonym for "bizarre".

[andreaferretti]

I have problems to figure out the type as well! :-D

For context, Nim's type inference does not perform unification - such as Hindley-Milner languages - but propagates type information forward only.

[Araq]

For context, Nim's type inference does not perform unification - such as Hindley-Milner languages - but propagates type information forward only.

Unification is forward only.

[andreaferretti]

Maybe we are talking about different things, but it is not forward only. To give an example, here is a definition of fizzbuzz without any type annotation in Haskell

fizz n | n `mod` 15 == 0  = "FizzBuzz"
       | n `mod` 3  == 0  = "Fizz"
       | n `mod` 5  == 0  = "Buzz"
       | otherwise = show n

If I enter this in GHCi and ask for its type I get

:type fizz
fizz :: (Integral a, Show a) => a -> [Char]   

Notice that it has propagated back the constraint that a is Integral from the fact that I use mod on a variable of type a and that it belongs to the typeclass Show because I call show in it. The type information has propagated from the usage of mod to the definition of fizz, hence backwards

[Araq]

Yes, Haskell and ML use a more complex scheme which propagates back. But the term "unification" is perfectly fine with forward only. Nim does perform unification.