[plt-scheme] MzScheme and .NET

"Pedro Pinto" <ppinto at cs.cmu.edu> writes:

> I am not sure I understand what you mean. Are you suggesting the use of
> reflection on a dynamic assembly to locate and invoke the target
> methods?

Yes, that's what I mean.

> 
> Is this what you mean? I thought about this to. While I appreciate
> the simplicity of not having to bother with compiling a wrapper, I
> abandoned the idea because I assumed performance would be
> considerably worse and I thought the syntax was very unnatural.

I was thinking of doing most of the work 'up front' with macros. So
Something like:

  (import-dot-net "blah.dll")

This would be a macro that at compile time analysed the assembly and
generated the wrapper code such that the calls would appear exactly
like the calls that were generated by the C3 program. This can be done
in Goo and Common Lisp and I'm fairly certain that the macro facility
of Scheme allows the same sort of flexibility at compile time.

The code would be slightly less efficient than that generated by the
external program but for interactive programming that would be fine
for me.

> Your marshaling code is strikingly similar to mine. I used the same
> storage strategy for .NET objects (did you consider pinning the .NET
> pointers and passing those instead? - I have yet to explore this)

I did try pinned pointers at one stage but I abandoned it for the
current approach. I can't recall why though. One thing with this
approach is you need a 'release' call from the Scheme side to remove
the object from the array allowing it to be garbage collected. Or use
finalizers to remove it when the lisp object is no longer referenced.

> 
> My difficulty was how to map the passing of a reference by reference
> to scheme. This could probably be faked when using a reference to a
> class but I have no idea how to do it for primitive types.

Currently I don't deal with it as very few .NET methods actually use
this. When I do get around to dealing with it I'd probably take one of
the following approaches:

1) Instead of making it a reference, from Goo accept it as an argument
   and also return the result as an extra return value.

 or

2) Pass the data in as an array holding the input value. The return of
   the function would set the value of that item in the array to the
   result.

One thing to keep in mind that in .NET primitive types can be boxed as
objects.

I'd prefer the first approach. But generally I look at the FFI as
being a low level interface that people wouldn't generally use. A more
Goo (or Scheme in your case) API would be written on top by the user.

Chris.
-- 
http://www.double.co.nz