[RFC] Interfaces in Nim

[dom96]

I've recently had a discussion about this with @Araq, so this is more of a reminder for myself and him, but comments are still welcome.

Araq's ultimate goal for Nim is to have a simple language with a powerful macro system. As such, interfaces in Nim should be implemented using macros.

Goals:

• Compatibility with the "fake" interface used in the streams module

Potential further research:

• Look into some of the many OOP/Interface packages to see how they have been implemented. Perhaps with the idea to adopt them into the stdlib in mind.

[andreaferretti]

I have one, https://github.com/andreaferretti/interfaced to which I have not contributed much, if anything. Actual work done by @krux02 and @RSDuck. Example of usage:

import interfaced

type
  Human = ref object
    name: string
  Dog = ref object

proc makeNoise(human: Human): string =
  "Hello, my name is " & human.name

proc legs(human: Human): int = 2

proc greet(human: Human, other: string): string =
  "Nice to meet you, " & other

proc makeNoise(dog: Dog): string = "Woof! Woof!"

proc legs(dog: Dog): int = 4

proc greet(dog: Dog, other: string): string = "Woof! Woooof... wof!?"

createInterface(Animal):
  proc makeNoise(this: Animal): string
  proc legs(this: Animal): int
  proc greet(this: Animal, other: string): string
    
proc interact(animal: Animal) =
  echo animal.makeNoise
  echo animal.greet("James Bond")

proc interactAll(animals: varargs[Animal, toAnimal]) =
  for animal in animals:
    animal.interact()

when isMainModule:
  var
    me = Human(name: "Andrea")
    bau = Dog()

  for animal in @[me.toAnimal, bau.toAnimal]:
    echo "Number of legs: ", legs(animal)

  interactAll(me, bau)

A nice addition (which is not there right now) would be to link interfaces to concepts (somehow derive one from the other)

[zielmicha]

Existing OOP/interface macros:

• https://github.com/jyapayne/nim-extensions/blob/master/oop_macro.nim
• https://github.com/flaviut/nim-by-example/blob/master/content/content/oop_macro.md (the same thing?)
• https://github.com/zielmicha/collections.nim/blob/master/collections/iface.nim
• https://gist.github.com/PhilipWitte/f4f0c18f7f6436ee87dc3c506343d859

I have tried to implement elegant interfaces using macros. (https://github.com/zielmicha/collections.nim/blob/master/collections/iface.nim). It works, but requires interface definition outside of type section:

type Duck = distinct Interface
interfaceMethods Duck:
  quack(number: int): string

Unless I'm missing something, macro system has a limitation - you couldn't emit code in type section.
For example, this won't work:

template bar(): untyped =
  proc fooFunc(): int =
    return 5

  int

type Foo1 = bar()

let a: Foo1 = fooFunc()

[zielmicha]

What about planned vtref? Are they cancelled?

[Araq]

What about planned vtref? Are they cancelled?

Given the current status of concepts, they are too fragile to base yet another complex feature on top of them. They are delayed, as far as I'm concerned. Probably @zah will chim in and disagree. :-)

[andreaferretti]

Maybe it would be useful to take a simple example of usage and express it using the different libraries in order to compare them

[krux02]

@andreaferretti whay are there ref types? I made sure that you don't need ref types for the interfaces.

Aparently the inteface libary has been spoiled with ref types, I would like to point you to the original version that I wrote in the forum that does not need any ref types at all:
https://forum.nim-lang.org/t/2422

[RSDuck]

I changed it to ref types, because otherwise there would be the risk of a dangling pointer. It could probably be done better, but since being ref type is also required for dynamic dispatch via method, I thought it wouldn't be that bad.

[krux02]

@RSDuck probably we should discuss this somewher else, but it is "that bad". I desigend the interfaces carefully, so that they can be used without any GC active. I am very careful about this, I don't want any ref types in my rendering thread. With your changes I can't use interfaces at all anymore in my rendering thread. And can you elaborate on "dangeling pointers"? Yes I use pointers internally to implement it, but so does C backend of Nim. The interface object is not supposed to keep anything "alive" it is supposed to be like a pointer.

[andreaferretti]

The issue tracker of interfaced can be a good place to discuss this

[Araq]

I think we can and should give the interface macro a parameter to either use ref or ptr under the hood.

[krux02]

Araq: well I don't think that's necessary. The macro can check if it is based on a ref type or anything else. My original implementation just didn't care for ref types, but I don't think it is necessary to have an additional parameter.

[Araq]

Maybe, but whether it produces a converter or not should also be optional.

[zah]

These library-based approaches will become unnecessary once the VTable types are ready, but otherwise I'm not against them especially if they will give us some experience.

Some aspects of the VTable types are already implemented. In particular @Araq hasn't merged yet one of my patches enabling the "Converter Concepts" feature, which can be used here as well to get a bit easier to use interface for the interface-based procs :) (i.e. you can have a converter concept automatically calling toAnimal at the call-sites). I'll rebase the patch soon.