Improve the foreign interface by allowing for foreign functions to be declared

[jimbxb]

Sometimes calling a foreign function can be a little clunky due to the repetitive nature of foreign calls. While this can be reduced by defining a Wybe "interface" as a series of functions that call their foreign counterpart, some language features could be used to resolve this.

Currently one would have to do something like this:

def putchar(c:char) use !io {
    foreign c putchar(c, !io)
}

!putchar('W')
!putchar('y')
!putchar('b')
!putchar('e')

# or verbosely:
foreign c putchar('W', !io)
foreign c putchar('y', !io)
foreign c putchar('b', !io)
foreign c putchar('e', !io)

I see two potential solutions to this:

1. Declare a foreign function as you would a Wybe proc

This could look something like as follows:

# putchar can now be used as a "first-class" Wybe proc
def foreign c putchar(c:char) use !io

!putchar('W')
!putchar('y')
!putchar('b')
!putchar('e')

This really only reduces boilerplate for the foreign code, but I see it being useful. For resources, they should be passed as regular arguments to the foreign function, and probably in some canonical order -- if you want to change that order then you can just use the old school version as above.

2. Automatically create a module based on some foreign file.

Peter has discussed this with me in the past, and I think his would be the best, but it certainly involves the most work (for good reason). In essence, given some foreign language file (perhaps an object file of some kind?) construct a Wybe module that acts as an interface to this module. This ideally would be performed in-source, to the effect of what follows:

foreign c module io

!putchar('W')
!putchar('y')
!putchar('b')
!putchar('e')

Of course, there would now have to be a C file that exists elsewhere that contains the relevant bindings, etc. for the module's procs, and I don't like the implicitness of it now that I'm writing it out. I'm not really sure how to approach this, which is why I believe the former is achievable.

[pschachte]

This would be really convenient, and the two halves are complementary; ie, I think the first idea would be useful even if the second idea is implemented. In fact, the second idea could be built on the first.

I don't think it would be possible to generate an interface based on an object file, because object files don't include the necessary type information. For C, it probably makes the most sense to generate the interface from a '.h' (header) file, after it's been run through CPP. From this you could generate Wybe types (based on typedefs and struct declarations), and Wybe procs (based on extern declarations).

[jimbxb]

Yep, I agree. The second would make the construction of a Wybe module from a C module just a little bit easier.

And yep, a header file makes more sense. My bad!