Re: Type instantiation for `==` func

2019-01-02 Thread LeuGim
@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.

Re: Type instantiation for `==` func

2019-01-02 Thread LeuGim
> 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,

Re: Type instantiation for `==` func

2019-01-02 Thread e
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

Re: Type instantiation for `==` func

2019-01-02 Thread LeuGim
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

Re: Type instantiation for `==` func

2019-01-02 Thread tim_st
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,

Re: Type instantiation for `==` func

2019-01-02 Thread tim_st
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

Re: Type instantiation for `==` func

2019-01-01 Thread e
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

Re: Type instantiation for `==` func

2019-01-01 Thread tim_st
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

Re: Type instantiation for `==` func

2019-01-01 Thread e
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]

Re: Type instantiation for `==` func

2019-01-01 Thread mratsim
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?

Type instantiation for `==` func

2018-12-31 Thread e
My first Nim library, so newbie warning... The library is a persistent balanced tree data structure that can be used as a map or a set. It's mostly working and tested, but I ran into trouble trying to make a generic == to match the built-in Nim set equality operator. Since the comparison is on