Mirror of forum.nim-lang.org

3655 :: Compile-time type reflection API?

• StasB (orginal) [2018-03-16T10:38:36+01:00] view original

  I know it's possible to get information by examining the AST associated with a type's symbol, but wouldn't it make more sense to provide a compile-time API that allows one to query it directly? For instance, something like TypeName.hasField("fieldName") or for field in TypeName.fields would be a lot more robust and easy to use than manually scanning the AST, and probably more efficient (I assume the compiler already keeps such information somewhere in a form that's efficient to query).

---

• Araq (orginal) [2018-03-16T15:42:45+01:00] view original

  The idea always was to have more convenient accessors for the ASTs that getType returns. But for now we're stuck with the primitives. :-)

---

• StasB (orginal) [2018-03-16T18:01:39+01:00] view original

  Doesn't the Nim compiler already have a set of such functions for internal use?

---

• Araq (orginal) [2018-03-16T22:02:59+01:00] view original

  Depends, but not really. An object does not only consist of fields, it can have case and when etc.

---

• chrisheller (orginal) [2018-03-16T22:34:33+01:00] view original

  Keep in mind that you can write some of your own compile time methods if (for example) you're regularly checking for something in the AST.

---

• StasB (orginal) [2018-03-17T08:24:22+01:00] view original

  @Araq:

  An object does not only consist of fields, it can have case and when etc.

  Which is part of the reason why doing something as simple as getting the fields robustly gets difficult when dealing directly with the AST; there isn't just one canonical representation. I thought the compiler might have such a canonical representation internally which can be queried, but I guess not.

  @chrisheller:

  Keep in mind that you can write some of your own compile time methods

  I did write my own (partial) solution. It just doesn't work for every valid tree configuration as of yet. If the plan is to write an API on top of the AST one anyway, then I guess I'll just keep building up on mine and release it eventually as a library when it becomes robust. Then someone could integrate into Nim core if it comes out any good.

---

• timothee (orginal) [2018-04-07T08:10:36+02:00] view original

  @Araq

  The idea always was to have more convenient accessors for the ASTs that getType returns. But for now we're stuck with the primitives.

  doesn't this solve the problem?

  type
      A=object
        x1:int
        x2:string
  
  for name, value in A().fieldPairs:
      echo name # etc
  Run

  (modulo this bug https://github.com/nim-lang/Nim/issues/7533)

---