HLL wrappers for Parrot wrappers for C libs

Geoffrey Broadwell geoff at broadwell.org
Tue Dec 23 23:01:46 UTC 2008


A friend of mine brought up an interesting idea for making C libs
available across multiple Parrot HLLs, and asked me to bring it up to
the Parrot team; I've summarized the discussion below.

As it currently stands, even when someone has written a generic PIR NCI
wrapper for some C library, HLLs commonly have to provide an additional
thin wrapper over that common PIR code to make the API usage feel more
'native'.  For example, languages that prefer exceptions over return
codes would want their wrapper to throw exceptions whenever the
underlying library calls returned a failure code.  Languages that can
return lists will want to convert C-style 'out' arguments to more
colloquial returned list items.  And so on.

His idea was to specify a sort of uber-IDL that could describe the
*semantic* meanings of various API call styles, plus provide tools that
would allow HLL implementors to write automated wrapper creators.  These
would take the semantic information about the raw API as input and
produce the necessary PIR to rewrap the common Parrot library in an
HLL-native call style as output.

Of course, this could only ever be an imperfect solution.  Thankfully,
as long as there was an escape hatch to override or supplement the
auto-wrapper tool output (similar to supplementing NQP with PIR), that
shouldn't be a real problem.

The benefit is that making a large standard library or library
collection (e.g. GTK+) available in all Parrot-hosted HLLs becomes much
easier.  With or without the auto-wrappers, you still need to do the
basic common NCI wrapper -- but then instead of having to manually write
higher-level wrappers for every HLL from scratch, 90-99% of the work is
done automagically, leaving only some tweaking for the HLL implementors
to do by hand.

Over time, as additional common "styles" of API are noticed, the
uber-IDL and tools can be updated, further reducing the manual tweaking
phase of the HLL implementor's job.

His argument for this as a useful core feature was roughly that it would
be the NCI equivalent of the difference that PCT makes -- you can't do
*everything* you need in PGE and NQP, but it vastly reduces the workload
in the common cases.


-'f




More information about the parrot-dev mailing list