Because issue does not affect objects and only affects tuples, the simple idea is that I should be able to debug nim complier run once with object and once with tuple, find the place where logic diverges and fix it.
Now the easy part :):), How debug workflow of Nim compiler?
I don't think it's a bug in the compiler. There is probably a good reason that you can not overload the [] operator for tuples. As you stated, you could either use objects instead or use a different operator. It works e.g. with the curly braces:
proc `{}`(dt: MyTable, ...
Also, since indexing starts at 0, you would need to do:
for i in 0..<nrow(dt): ...
and the nrow proc could be simplified to:
proc nrow(dt: MyTable) : Natural {.inline.} = dt.name.len
Hi Chemist69,
Why I can overload [] operator for seq[T], but not for tuple? This works for example:
proc `[]`[T](s : seq[T], keys: seq[bool]) : seq[T] =
result = newSeqOfCap[type(s[0])](s.len)
for i in 0..<s.len:
if keys[i]: result.add(s[i])
let
a = @["x1", "x2", "x3", "x4"]
b = @[true, false, false, false]
echo a[b]
As far as I can tell, nonoverloadable [] operator for tuple is oversight rather then a need.
All other comments regarding nrow and indexing starts from zero, these artifacts appeared when I was cutting down the code to a minimum reproducible example. In real project everything implemented in a different, more complicated way. nrow accepts a concept and does not know the names of the tuple fields. Tuple is not defined explicitly and is coming from user and can be different for every query. I can't force a user to define object type for every query they make.
I don't know if it's a compiler bug or not, the manual says The [] subscript operator for arrays/openarrays/sequences can be overloaded. but eg in macros and I think tables it's used.
Anyway, for me on git hash: b7bffa35c70eb1a55fe9e35307ba4e99e48abe69
echo x["p2"] # subscript operator
echo `[]`(x, "p2") # call syntax
Mostly you have to build a debug compiler ( koch temp ) and then use this version (normally it's nim_temp in your nim/bin folder) to run your test.
Eg. traceback with nim_temp c -r test.nim
Traceback (most recent call last)
nim.nim(121) nim
nim.nim(77) handleCmdLine
main.nim(163) mainCommand
main.nim(74) commandCompileToC
modules.nim(240) compileProject
modules.nim(180) compileModule
passes.nim(215) processModule
passes.nim(135) processTopLevelStmt
sem.nim(536) myProcess
sem.nim(508) semStmtAndGenerateGenerics
semstmts.nim(1679) semStmt
semexprs.nim(828) semExprNoType
semexprs.nim(2268) semExpr
semexprs.nim(1905) semMagic
semexprs.nim(811) semDirectOp
semexprs.nim(649) semOverloadedCallAnalyseEffects
semcall.nim(388) semOverloadedCall
semcall.nim(211) resolveOverloads
semcall.nim(91) pickBestCandidate
sigmatch.nim(2044) matches
sigmatch.nim(2001) matchesAux
sigmatch.nim(1836) prepareOperand
semexprs.nim(26) semOperand
semexprs.nim(2294) semExpr
semexprs.nim(1315) semArrayAccess
semexprs.nim(1280) semSubscript
msgs.nim(1030) localError
msgs.nim(1018) liMessage
msgs.nim(872) handleError
msgs.nim(857) quit
Thank you Stisa! That is the way to go.
I managed to patch semSubscript at semexprs.nim in no time.
Expect pull request in the near future.
Thanks Stisa, Your comment was crucial to find the spot issue in the code. The fix is now submitted to the Nim devel branch https://github.com/nim-lang/Nim/commit/c6a8bd264e77da69fc95de17a7febe5a32955a40
I am impressed one more time with efficiency and simplicity of Nim compiler design, it is quite pleasant to work with. I encourage everyone to give it a try to contribute.