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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
