@e:
To make it work `node != nil` in `contains` (`bbtree.nim#612`) needs to be
changed to `not node.isNil`. It's used from both `==` and `<=`, error messages
hint to that.
> if it's that obvious
What looks obvious is that error is not because of procedure's name (`==`) -
you may test it with changing it to some different name.
`len` \- yes, it's in the library, I didn't see the librarythen, tried the
snippet from the original post.
Trying the library itself, err
So, digging deeper, the place where the generic instantiation is losing is
while curr != nil or stack.len > 0:
Run
So, the compiler can't infer a type for nil. It hadn't occurred to me to look
for !=. If I replace that line with
while (not curr.isNil) or stack
But error message clearly says that you have no `len` procedure for `BBTree`.
Just define it. Or maybe you meant to use `size` field in `BBtree` for that.
You may after all rename `==` to whatever else (some `^&%`) and see the error
message not changing - it has nothing to do with the function's
There is a len func func len*[K,V](root: BBTree[K,V]): int = ... but the
compiler doesn't match it similiar to this issue
[https://github.com/nim-lang/Nim/issues/9606](https://github.com/nim-lang/Nim/issues/9606)
. I tried the code by explicitly call filename.len to force the correct match,
but
I replaced some generic parameters in your code with untyped templates and then
always new errors appeared in procs that were called from the proc that showed
the error, so it seems you have somewere the real bug, but the compiler can't
show you the correct place (I've seen this behaviour before
Having thought about this for a while, I am not advocating for a fix. I was
hesitant to define the == func at all since it is comparing keys but not
values, It is called set-equal? in MIT/Scheme wttree, not equal?. I only
considered adding it to make the unit tests line up with other Nim set lib
Seems like a compiler bug. Workaround:
func `==`*(s1: BBTree, s2: BBTree): bool {.inline.} =
## Returns true if both `s1` and `s2` have the same keys and set size.
result = isSubset(s1, s2) and len(s1) == len(s2)
Run
Sure, here are the relevant bits:
type
BBTree*[K,V] = ref object # BBTree is a generic type with keys and
values of types K, V
## `BBTree` is an opaque immutable type.
left: BBTree[K,V] # left subtree; may be nil
right: BBTree[K,V]
I don't see a reason why it would fail to compile.
Can you also add your BBTree and isSubSet type declaration so that we can
reproduce a minimal working example?
10 matches
Mail list logo