[RFC] removing library NCI signatures from core

[Andrew Whitworth]

On Wed, Feb 17, 2010 at 7:27 AM, NotFound <julian.notfound at gmail.com> wrote:
> Be extended how? Generating and compiling C code is a big NO. That way
> NCI is not native at all. It kills the posibility of installing pir
> modules that use NCI in machines without a C compiler, forcing you to
> use some development system and reinstall parrot or parts of it.

That's how Parrot is now, except when we want to add a new NCI
signature we need to recompile all of Parrot. Because of the Perl5
dependency, it's actually harder to do this than just compile a shared
library.

Compilation of C code libraries is a chore, but it's only one option.
Using libjit, libffi, or other libraries would make the process
significantly easier in the future. These alternatives could be
pluggable once the system is cleaned up and we remove static thunks.

> And we don't need a native interface to do that, the extension can
> just provide functions with signatures that parrot expects or
> provides. Just like perl5 extensions.

Now that's quite an interesting idea, but limiting. We need some kind
of way to construct a call frame in order to provide a thin wrapper
around an external library. If we create a more "thick" wrapper
instead, such as a PMC class to wrap the interface, or a set of ops,
we can do what you suggest. I don't like the idea of restricting what
kinds of add-ons we can support, however. Some libraries don't lend
themselves to being wrapped by a PMC or even a set of PMCs.

>> * there will be a new, more flexible (IMHO better) way to get
>> signature thunks for extenders/embedders
>
> Fine, but in that case let's keep the current way until we have that
> other new way.

As a middle-ground first step, howabout we break the non-necessary NCI
signatures into a dynlib in the repo. That way we still have them in
the repo if needed in the interim, we have a way to run tests on the
mechanism locally, and we prepare for the larger refactors that Peter
is suggesting.

> I like to be able to access any public function in any dynamic library
> of the system from pure pir, hand written or generated, without
> compiling and installing anything, even with a parrot buit before that
> library existed. That's what I believe a Native interface is.
> Otherwise is just an extension mechanism.

That's what we all want, but we cannot do that now. What we do now is
really the worst possible solution, and making loadable libraries of
NCI thunks is a huge improvement over that. In reality, we're probably
not going to have proper dynamic native calls  without one of two
things: an existing dynamic interface (using libffi or libjit) or
Lorito.

--Andrew Whitworth