On Mon, May 31, 2010 at 3:06 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:

[please always reply to the list]

Sorry. :-/

Jason Baker, 31.05.2010 21:45:

...

On Mon, May 31, 2010 at 2:05 PM, Stefan Behnel wrote:

...

Jason Baker, 31.05.2010 18:15:

...

I'm working on a Python-to-mzscheme binding using mzscheme's ffi library (mzscheme's rough equivalent of the Python ctypes library).

Since you didn't provide the link (and "mzscheme ffi" doesn't get me anything that looks right at first sight), am I right in guessing that you might be referring to this?

http://download.plt-scheme.org/doc/351/html/foreign/

That's an older version of the docs, but yes. Here's a more recent link: http://docs.plt-scheme.org/foreign/index.html

...

...

...

I'm looking for a way to convert Python objects into Scheme values. Essentially what I'm trying to do is say "Is this a Python  integer? Ok, convert it to a Scheme integer."  or "Is this a Python string? Ok, convert it into a Scheme string."  ... etc.

What is the best way to do this?  My first intuition was to call Py*_Check to determine the type, but it turns out that's a macro that can't be used in non-c code.  I'm sure I could translate that into the appropriate C code, but that gives me a bad feeling.

Those are macros because that makes them really, really fast, especially in Py3. However, their definition changes between Python versions, so replacing them by regular C code is really not a good idea.

In general, I wouldn't try to make the wrapper too generic. You might want to inspect the underlying Scheme code (potentially at runtime), and infer the possible types (or the required conversion) from that.

Perhaps I should clarify. For now, I'm just trying to embed the python interpreter in Scheme.  Thus, I know what types the scheme values are, and I know how to translate them into the appropriate Python values. What I'm trying to figure out is how to go the other way.  That is, how do I figure out what type a PyObject is so I know how to create the appropriate Scheme value?

Why not write a type checking cascade in plain C or Cython?

I suppose I could, but I'd rather write it in pure Scheme or Python if at all possible. If that's not efficient enough, I can look into adding C into the mix.

...

...

...

Right now, I'm looking for simple and easy more than efficient and complete (but I would also like to know what the efficient and complete approach would be).

Have you considered integrating this with Cython via a thin C bridge, instead of talking to Python's C-API directly? Without knowing anything about the FFI you are using here, I suspect that it likely wouldn't be a generic wrapper in that case. Instead, it would allow users to write specialised and well optimised Scheme wrappers for their specific use case. So far, Cython supports calling into C, C++ and Fortran, where the Fortran wrapper is also implemented as a C-bridge (via fwrap). A similar Scheme binding would allow users to take advantage of Cython's static typing features, so that your code wouldn't have to guess types in the first place.

While I'm sure this approach works for C, C++, and Fortran, I'm afraid I don't see how this would apply to Scheme.  Scheme is a dynamically typed language just like Python.  Why do I want a layer of static typing in between two dynamically typed languages?

Scheme is a strictly typed language, though, and your Scheme code won't run with (or even accept) arbitrary Python input value types, just like your Python code won't run with arbitrary Scheme value types as input. So you have to draw the line somewhere. And since you are using an FFI, which, I assume, passes through C anyway, you might just as well restrict your glue code to suitable types.

I suppose I could use tagged pointers[1], but I was wanting something more generic (in other words, an interface that automatically does the right thing). Perhaps I'm biting off more than I can chew though.

[1] http://docs.plt-scheme.org/foreign/Derived_Utilities.html#(part._foreign~3at...)

On Mon, May 31, 2010 at 3:06 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:

[please always reply to the list]

Sorry. :-/

Jason Baker, 31.05.2010 21:45:

...

On Mon, May 31, 2010 at 2:05 PM, Stefan Behnel wrote:

...

Jason Baker, 31.05.2010 18:15:

...

I'm working on a Python-to-mzscheme binding using mzscheme's ffi library (mzscheme's rough equivalent of the Python ctypes library).

Since you didn't provide the link (and "mzscheme ffi" doesn't get me anything that looks right at first sight), am I right in guessing that you might be referring to this?

http://download.plt-scheme.org/doc/351/html/foreign/

That's an older version of the docs, but yes. Here's a more recent link: http://docs.plt-scheme.org/foreign/index.html

...

...

...

I'm looking for a way to convert Python objects into Scheme values. Essentially what I'm trying to do is say "Is this a Python  integer? Ok, convert it to a Scheme integer."  or "Is this a Python string? Ok, convert it into a Scheme string."  ... etc.

What is the best way to do this?  My first intuition was to call Py*_Check to determine the type, but it turns out that's a macro that can't be used in non-c code.  I'm sure I could translate that into the appropriate C code, but that gives me a bad feeling.

Those are macros because that makes them really, really fast, especially in Py3. However, their definition changes between Python versions, so replacing them by regular C code is really not a good idea.

In general, I wouldn't try to make the wrapper too generic. You might want to inspect the underlying Scheme code (potentially at runtime), and infer the possible types (or the required conversion) from that.

Perhaps I should clarify. For now, I'm just trying to embed the python interpreter in Scheme.  Thus, I know what types the scheme values are, and I know how to translate them into the appropriate Python values. What I'm trying to figure out is how to go the other way.  That is, how do I figure out what type a PyObject is so I know how to create the appropriate Scheme value?

Why not write a type checking cascade in plain C or Cython?

I suppose I could, but I'd rather write it in pure Scheme or Python if at all possible. If that's not efficient enough, I can look into adding C into the mix.

...

...

...

Right now, I'm looking for simple and easy more than efficient and complete (but I would also like to know what the efficient and complete approach would be).

Have you considered integrating this with Cython via a thin C bridge, instead of talking to Python's C-API directly? Without knowing anything about the FFI you are using here, I suspect that it likely wouldn't be a generic wrapper in that case. Instead, it would allow users to write specialised and well optimised Scheme wrappers for their specific use case. So far, Cython supports calling into C, C++ and Fortran, where the Fortran wrapper is also implemented as a C-bridge (via fwrap). A similar Scheme binding would allow users to take advantage of Cython's static typing features, so that your code wouldn't have to guess types in the first place.

While I'm sure this approach works for C, C++, and Fortran, I'm afraid I don't see how this would apply to Scheme.  Scheme is a dynamically typed language just like Python.  Why do I want a layer of static typing in between two dynamically typed languages?

Scheme is a strictly typed language, though, and your Scheme code won't run with (or even accept) arbitrary Python input value types, just like your Python code won't run with arbitrary Scheme value types as input. So you have to draw the line somewhere. And since you are using an FFI, which, I assume, passes through C anyway, you might just as well restrict your glue code to suitable types.

I suppose I could use tagged pointers[1], but I was wanting something more generic (in other words, an interface that automatically does the right thing). Perhaps I'm biting off more than I can chew though.

[1] http://docs.plt-scheme.org/foreign/Derived_Utilities.html#(part._foreign~3at...)