Basically, I am hit pretty badly with following issue and I wanted to try to fix it Nim compiler

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?

2017-04-20 10:26:51
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, ...
2017-04-20 11:32:03

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.} =

2017-04-20 11:42:05

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])

  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.

2017-04-20 13:10:53

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

  • Tuple and object versions with subscript operator both don't work
  • Object version with call syntax doesn't work
  • Tuple version with call syntax works.

echo x["p2"] # subscript operator
echo `[]`(x, "p2") # call syntax
For debugging the compiler, have a look at this .

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

2017-04-20 13:23:32

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.

2017-04-20 15:15:41
I just wanted to comment, that tuples have already a [] operator. They accept a static int n as argument and return the n-th element of that tuple. It is not overloadable, but I guess all you have to do is to make it overloadable by handling the magic in magicsAfterOverloadResolution.
2017-04-20 15:34:05

Thanks Stisa, Your comment was crucial to find the spot issue in the code. The fix is now submitted to the Nim devel branch

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.

2017-04-24 21:45:10
This is great, i had this issue too in the past, and i'm glad it was easy to fix. Good work cdome and good catch Stisa. 2017-04-26 07:34:59