From https://nim-lang.org/docs/tut2.html#templates
The !=, >, >=, in, notin, isnot operators are in fact templates.
There is also
https://nim-lang.org/docs/system.html#%3E%3D.t%2Cuntyped%2Cuntyped
easy to find from https://nim-lang.org/docs/theindex.html
Since your original question is already answered, here is one neat trick you can use:
const letters = toSeq('a'..'z').toSet()
or even
const letters = {'a'..'z'}
Thanks everyone for your help! My code has been cleaned up quite a bit:
from strutils import toLowerAscii
from sequtils import toSeq
from sets import toSet, `<=`
const letters = toSeq('a'..'z').toSet()
func isPangram*(text: string): bool =
return toSet(text.toLowerAscii()) >= letters
However I'm still getting the same compiler error. I read about templates, but perhaps I have more reading to do? I don't understand why if I import <= from sets, I get the compile error, but if I import everything from sets, it works just fine. I tried not importing <= in case the proper functioning operator was coming from system, but that doesn't seem to be the case.
10 months later, MrZoraman's sample code now compiles without errors with nim 1.0.4. But I have the same strange error about type error on items, and like MrZoraman I don't understand how it can happen.
I have 2 modules, bb.nim and cc.nim that imports bb.nim. When compiling cc.nim, I got the error:
$ nim c cc
Hint: used config file '.choosenim/toolchains/nim-1.0.0/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: cc [Processing]
Hint: hashes [Processing]
Hint: bb [Processing]
Hint: tables [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: sets [Processing]
cc.nim(21, 12) template/generic instantiation of `addConstraints` from here
bb.nim(12, 45) template/generic instantiation of `+` from here
.choosenim/toolchains/nim-1.0.0/lib/pure/collections/sets.nim(487, 17) template/generic instantiation of `union` from here
.choosenim/toolchains/nim-1.0.0/lib/pure/collections/sets.nim(411, 7) template/generic instantiation of `incl` from here
.choosenim/toolchains/nim-1.0.0/lib/pure/collections/sets.nim(211, 15) Error: type mismatch: got <HashSet[cc.Constraint]>
but expected one of:
iterator items[T](a: seq[T]): T
first type mismatch at position: 1
required type for a: seq[T]
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items(a: string): char
first type mismatch at position: 1
required type for a: string
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items[IX, T](a: array[IX, T]): T
first type mismatch at position: 1
required type for a: array[IX, T]
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items[T](a: set[T]): T
first type mismatch at position: 1
required type for a: set[T]
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items(a: cstring): char
first type mismatch at position: 1
required type for a: cstring
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items[T](s: HSlice[T, T]): T
first type mismatch at position: 1
required type for s: HSlice[items.T, items.T]
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items[T](a: openArray[T]): T
first type mismatch at position: 1
required type for a: openArray[T]
but expression 'other' is of type: HashSet[cc.Constraint]
iterator items(E: typedesc[enum]): E:type
first type mismatch at position: 1
required type for E: type enum
but expression 'other' is of type: HashSet[cc.Constraint]
expression: items(other)
If I merge both modules in one with cat bb.nim cc.nim > dd.nim and comment out the import bb line, then dd.nim compiles without errors.
The problem appears on the line:
constraints[choice] = constraints[choice] + consts.toHashSet()
constraints[choice].incl(consts.toHashSet())
What the compiler does not like? I don't have partial imports. Where is the problem? In my code or in the libraries?
bb.nim
import tables
import sets
type
Constraints[T, V] = Table[T, HashSet[V]]
proc initConstraints*[T, V](): Constraints[T, V] =
result = Constraints(initTable[T, initHashSet[V]()]())
proc addConstraints*[T, V](constraints: var Constraints[T, V], choice: T, consts: seq[V]) =
#if choice in constraints:
constraints[choice] = constraints[choice] + consts.toHashSet()
# constraints[choice].incl(consts.toHashSet())
#else:
# constraints[choice] = consts.toHashSet()
cc.nim
import hashes
import bb
type
Choice = object
i: int
Constraint = object
j: int
proc hash(c: Choice): Hash =
result = Hash(c.i)
proc hash(c: Constraint): Hash =
result = Hash(c.j)
var constraints = initConstraints[Choice, Constraint]()
let choice = Choice(i: 1)
let constSeq = @[Constraint(j: 2)]
constraints.addConstraints(choice, constSeq)
template/generic instantiation of + from here
This means + is generic and the real operation/error is elsewhere.
Error: type mismatch: got <HashSet[cc.Constraint]>
but expected one of:
iterator items[T](a: seq[T]): T
first type mismatch at position: 1
required type for a: seq[T]
.....
Means something error happened to make the compiler couldn't expand to items iterator.
You need to expand it by yourself to find out.
proc addConstraints*[T, V](constraints: var Constraints[T, V], choice: T, consts: seq[V]) =
for c in consts:
constraints[choice].incl c
This will lead to interesting error yet it's crucial that, constraints has no key of i:1 (of course, it the choice arg supplied). If you know the actual error, then you just modify your code to
proc addConstraints*[T, V](constraints: var Constraints[T, V], choice: T, consts: seq[V]) =
let hasKey = choice in constraints:
for c in consts:
if hasKey:
constraints[choice].incl c
else:
constraints[choice] = @[c].toHashSet()
That way you avoid the KeyError that thrown out.
Thanks mashingan for showing how to work around the error message.
I just wanted confirmation that the problem is on the compiler side or the libraries and not in my minimal code before opening an issue. The strange thing is that the errors does not always appear, as I've shown when you use a single file instead of 2 modules.
Like found by MrZoraman who opened that thread for the same compiler error, this bug is based on a small change in the code making it appear or not. It does not appear any more with the current compiler version for his code.