On 09/09/2008, at 8:47 AM, john skaller wrote:
>
> On 08/09/2008, at 11:42 PM, Jacques Carette wrote:
>
>> Neat.
>>
>> The one obvious question is: how many of those 'Py' are actually
>> needed, and how many are your choice of naming?
[]
> My convention wrapping foreign libraries at the low level is to
> duplicate the interfaces
> rather faithfully, so functions and types named Py_INCREF and PyObject
> etc retain their
> original names to help remind the user that they're low level wrappers
> and behave
> the same as documented in the foreign library docs.
There's another issue here. Suppose you write:
cfun mypy (x:int, y:int) => x + y;
export python fun mypy of (int * int) as "MyPy";
Well, of course this won't work, because the C function doesn't
conform to Python calling conventions. Python has some support
for converting Python values to C ones and vice versa, for example
stuff like:
PyCIntFromPyInt(int *, PyObject *)
(this isn't a real function, just an example). Now Felix might examine
the interface of "mypy" and generate wrapper code automatically.
Not all functions would have boilerplate conversions, but it would
save a LOT of work. So ...
The problem is the compiler would need *builtin* knowledge
of Python types. Indeed it is worse .. it would need *builtin* knowledge
of C types -- which it does not really have!!
And there's another problem when PyBuildTuple() etc are used,
since these are variadic functions.
Anyhow to have ANY hope of automatic wrapping here, the compiler
must "cheat" a bit as it does for C types (particularly in the Why proof
obligation generator) .. it uses the *known* type name to lookup the
type definitions. Which all means .. the type names like PyObject
must be fixed and they must be at the top level or in a known
module (so the compiler knows where to search).
--
john skaller
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
