Discussion of the Felix language syntax and semantics, architecture, type system, lookup model, compilation model, and conformance model. ()

Jacques Carette | 8 Sep 2008 15:42

Re: Python generator

Neat.

The one obvious question is: how many of those 'Py' are actually needed, 
and how many are your choice of naming?  In other words, could you 
rewrite that piece of Felix code for us, keeping the occurrences of 'py' 
[in any casing, appearing anywhere in the program] to an absolute minimum?

Jacques

john skaller wrote:
> Here is how it goes now:
>
> First, I put this file in directory config:
>
> Macintosh:fbld johnskaller$ cat config/python.fpc
> Name: Python
> cflags: -I/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ 
> Python.framework/Versions/2.5/include/python2.5/
> includes: "Python.h"
> requires_dlibs: -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/ 
> libpython2.5.dylib -lpython2.5
>
> This is for Mac OSX 10.5, using the system Python. Next, here is the  
> test program:
>
> Macintosh:fbld johnskaller$ cat pytest.flx
> requires package "Python";
>
> type PyObject = "PyObject*";
> proc Py_INCREF: PyObject = "Py_INCREF($1);";

(Continue reading)

headers

john skaller | 9 Sep 2008 00:47

Re: Python generator

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?  In other words,  
> could you rewrite that piece of Felix code for us, keeping the  
> occurrences of 'py' [in any casing, appearing anywhere in the  
> program] to an absolute minimum?

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. The one sop to  
faithfulness here
is that Felix PyObject actually represents a PyObject*.

Don't forget, Python isn't the only foreign library one might wrap..  
if we wrapped
Lua and Ruby as well, we might have rather an overload of "Object"  
types, for
example.

Having said that .. of course one can use modules/namespaces:

module Py {

(Continue reading)

headers

john skaller | 9 Sep 2008 01:13

Re: Python generator

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:

(Continue reading)