[RFC] removing library NCI signatures from core

[Peter Lobsinger]

On Wed, Feb 17, 2010 at 7:27 AM, NotFound <julian.notfound at gmail.com> wrote:
>> * parrot core should only contain the minimum necessary to run and be extended
>
> 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.

The 2 major ways to extend parrot, dynpmcs and dynops, already need a
C compiler. For machines without a C compiler, there must be a C
compiler somewhere or else you wouldn't have parrot. Additional static
signatures would not be difficult to add at parrot's compile time -
modify call_list.txt, regenerate src/nci.c, and recompile (what we
have now btw).

But static signatures have a cost of requiring the interpreter to haul
around a hash (~400 elements) of thunks that are hardly ever used.
These bloat both the gc pool and the code size. For users that don't
need it, why have it?

> 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.

perl5 extensions would be great at this point. Our nci system doesn't
even have that yet. There's an important point to perl5 extensions
that we're lacking - a boilerplate generator. And that's what
nativecall.pir provides.

>> * 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.

A number of people seem to believe that this better way is a runtime
thunk generator. That won't work everywhere. There will always be some
architecture to which whatever ffi library you use has not yet been
ported.

That's not to say that a runtime thunk mechanism isn't worthwhile,
just that it excludes potential platforms. We should provide a way
that is fully generic, if a bit cumbersome for some.

> 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 mis-characterizes what NCI in parrot is right now. NCI in parrot
currently only works for a narrow set of libraries that have been
registered in config/gen/call_list/misc.in. If the library you want
isn't there, and you've created bindings that "work", they only work
by accident.

And the set of currently supported signatures isn't that great either.
I initially got into the nci system because I was trying to embed
parrot and a simple 3 argument signature I was trying to use wasn't
supported. I could have added my project and associated signatures to
config/gen/call_list/misc.in and been on my merry way, but that's a
band-aid solution.

Whether we should call this a native call interface or not doesn't
really matter to me. If it doesn't do what people expect an nci system
to do, we could just as easily call it something else so people don't
get any misleading expectations.