Mirror of forum.nim-lang.org

1294 :: Chaining converters automatically?

• OderWat (orginal) [2015-06-04T16:48:28+02:00] view original

  Imagine we have a type A and a type B with:

  • a converter to convert from string to type A, like converter toA(s: string): A = ...
  • a converter which converts from type A to type B, like converter toB(a: A): B = ...

  Now think of a proc which expects type B like proc doSomethingWith(b: B) = ....

  I can create a converter converter toB(s: string): B = toB(toA(s)) to make the proc accept a string as parameter. But wouldn't it possible to let the compiler figure this out automatically?

---

• Stefan_Salewski (orginal) [2015-06-04T17:37:55+02:00] view original

  I asked a similar question some weeks ago, hoping that smart converters would make it very easy to add GC support to GTK3. From Jehan's answer, it seems that only direct conversion is possible, see

  http://forum.nim-lang.org/t/1181

---

• OderWat (orginal) [2015-06-05T00:15:50+02:00] view original

  Well in your example its not a simple "input -> converter -> tpm -> converter -> output" relationship I think. I may not fully understand your example though. Still I think the case I listed could be solved because there is just a tight number of possible combinations for the converters to line up. Find the converter chain A -> B -> C if you have A->B A->D B->C D->E for example... only using "converter".

---

• Jehan (orginal) [2015-06-05T00:45:55+02:00] view original

  It is possible, but can be expensive (transitive closure) and can lead to behavior that is difficult to predict.

---

• OderWat (orginal) [2015-06-05T02:58:31+02:00] view original

  Sounds like macros and meta programming in gerneral :)

  The compiler could give a warning where it is used and one could use a pragma to enable this resolution for chosen converters individually, even giving a hint about the direction (input or output) for the connections could be defined and help to reduce such problems.

  But then I think it is not to hard to just write the ones I need manually. I just did that tonight with a couple of them and it's pretty nice to have no "other effects" coming in the way and see a clear list of whats available.

---

• Araq (orginal) [2015-06-06T16:35:06+02:00] view original

  A converter is actually much more like a TR macro in this regard with its "spooky action at a distance" (there is nothing in the source code that suggests it is invoked). So converters are dangerous (TM) and not transitive. Whether easy or hard to implement has not much to do with these restrictions.

---

• Stefan_Salewski (orginal) [2015-06-06T20:02:53+02:00] view original

  Recently, when I understood that chaining of converters is too complicated, I wondered if template like converters may be possible. Current converters have a well defined return type and behave like magically called procs. It would be nice to have a converter with well defined parameter type but expr result. Application may be: I put a GTK widgets into a Nim object to do GC. When calling GTK library function now, I have to write something like gtk3.set_text(nimWidget.gtkWidget, "Text"). If there was a converter-template like

  template nimobject2gtkwidget(o: NimGtkObj): expr =
   o.gtkWidget

  then gtk3.set_text(nimWidget, "Text") may work. Obviously it is necessary that there exists not more than one of these converters for a data type. The benefit would be that we have to write less glue code for high level wrappers. (Otherwise, we have to write for many library functions a companion proc with a NimObject parameter which calls the library function with the library pointer.)

---

• Varriount (orginal) [2015-06-06T20:39:21+02:00] view original

  @Stefan_Salewski The problem with your idea is that it would be very difficult for the the compiler to determine when such a converter should be invoked. Current converters can be looked up by the compiler whenever there is a type mismatch. On what event would the compiler invoke a converter returning an expression?

---

• Araq (orginal) [2015-06-06T21:05:11+02:00] view original

  @Varriount But the input type is known for this template, only the return type is inferred. Looks quite easy to support.

---

• Stefan_Salewski (orginal) [2015-06-06T21:07:18+02:00] view original

  Sure it is difficult, maybe the effort is not justified. The logic is: There can exist only one of this type of converter for a data type. When the compiler noticed that a data type is not compatible in an expression, it may first try to use ordinary converters and other logic a now. If that does not work, it may try this new type of converter with expr result and use that expression. So that new type of converter has lowest priority, maybe its use is also restricted to C library calls. My feeling was, that it may be useful for libraries like GTK, I don't know if it may be useful for other C libraries also. The advantage would be, that we have not to generate so much additional code for high level wrappers. (the code generation may be not the problem, scripts may do that , but I do not really like the bloat.)

---