In my code, the compiler does not like the way I return the solve closure iterator with generic parameters and prints the error 'solve' doesn't have a concrete type, due to unspecified generic parameters.
I don't understand the reason for such message, as both generic parameters are instantiated by the call of the enclosing proc.
Also, note that if you remove the second generic parameter of the solve iterator, using the following code, now the program compiles...
...
iterator solve[T]: Solution[T] {.closure.} =
yield solution
try:
return solve[T]
...
Of course, in the original code, I need both T and V generic parameters in real solve.
Is there someone that could explain what's wrong with that code and why the compiler complains? I don't understand the reason for the error message and I don't know how to change the code to correct it.
Thanks
Does this changed version of your code still do what you need? https://play.nim-lang.org/#ix=25Fy
I found that you don't need the extra type parameters around your solve iterator: T and V are already coming from allExactCover. You may also need to look at how you are creating your HashSet c; the creation proc needs to know the type ([V]).
Good luck!
Information of T and V already available from parent function so your iterator doesn't have to generic. Also, if a function cannot infer from argument, the workaround is that you have to be explicit.
proc allExactCover*[T, V](constraints: Constraints[T, V]): iterator (): Solution[T] =
var
solution: Solution[T]
iterator nilIterator: Solution[T] {.closure.} =
yield @[]
iterator solve: Solution[T] {.closure.} =
var c = initHashSet[V]()
yield solution
try:
return solve
except KeyError:
return nilIterator
proc sdk: iterator (): Solution[Choice] =
var constraints = initConstraints[Choice, Constraint]()
return allExactCover[Choice, Constraint](constraints) # explicitly tell the type
Thank you, I understand now!
In case of inner procs, the generic context is already defined for them coming from the outer proc and you don't need to redefine it (but if you introduce new generic parameters).
If the compiler had issued a warning that I was redefining already existing generic variables in the inner procs, it would have given me a hint of the problem. I had tried using other generic variable names in the inner procs without success and I was stuck with that strange compiler error message about generic instanciation... Now it make sense.
Perhaps this rule about generic scope and inner procs should be listed in the documentation.
Thanks again @hyl and @mashingan!