[plt-scheme] "define-cunion" prototype for FFI

I can't make any claims about the quality of my code (although I  
tried to follow the style that the existing foreign.ss code used),  
but I tried to minimize the effect my code had on the existing  
library. In order to avoid excess code duplication from the cstruct  
code I think that there's a good case to include it into the module  
itself.

I had to change the existing definition of "define-cstruct" slightly  
to get this to work. These changes mainly consisted of pulling out  
some of the "function-local" functions from the syntax definition  
into a begin-for-syntax block ahead of time, so two syntax  
definitions could share it. The alternative was to use something like  
define-syntaxes to define both in unison, but perhaps in my ignorance  
I couldn't find a convenient place to define all of the inner- 
definitions where both transformers could share the functionality  
(unless defining those functions as let-bindings is considered good  
style).

Correct me if my understanding is flawed, but unions are notably  
simpler than structs, given that most of the alignment issues can be  
avoided since all of the "fields" have a pointer offset of 0. In that  
regard, the only remaining issues is ensuring that the union type has  
the correct size, which should be the maximum size of it's members.  
So in the end, it looks like I'm working on the same level as define- 
cstruct, which would at first examination be the natural level to put  
it.

It may be easier to understand this if I made the code available. If  
anyone is interested in seeing the current incarnation of the code,  
I'm more than willing to post it up somewhere. Any comments,  
complains, or insults are appreciated :-).

- Brian Chin

> On Nov 10, Brian Chin wrote:
>> Hey all,
>>
>> Needing a way of representing C unions in the MzScheme FFI, I dug
>> into the foreign.ss file and coded up a "define-cunion" form bearing
>> many similarities to (and sharing much code with) the existing
>> define- cstruct code. The syntax to define a union is identical to
>> the struct version (although you are not allowed to use a structure
>> supertype), and the created functions have the same interface, with
>> the exception of make-TYPE, which instead of taking one argument per
>> field (which would make little sense for a union), you pass it the
>> symbol of the field you want to fill, and the value you want to fill
>> that slot with. I've done some brief testing, and the code seems to
>> be complete, except:
>>
>> - The functions list->TYPE and it's brethren are still created for
>> unions, even though they have next to no meaning in this framework
>> - You can still provide a union as a supertype for a new struct. The
>> behavior in that case is untested, undefined, highly volatile, and
>> confusing.
>>
>> I haven't participated in this mailing list enough to know what the
>> right procedure for submitting these patches are, so I guess I have
>> three questions:
>>
>> 1. Is this a useful addition to the FFI library? It preserves the
>> semantics of the existing library, and with a little work should
>> interact well with the other features.
>
> Yes, not having unions is one of the limitations of libffi.  Another
> important one is the lack of vector types.
>
>
>> 2. If 1, _should_ it be added to MzScheme?
>
> That, however, is questionable.  I'm not dismissing your scheme code
> (which I haven't seen) -- but if you started from foreign.ss, then you
> might have been working at the wrong level.  To make unions work as
> the should, it's important that the resulting type have the right size
> and alignment information.  This is required to be able to use unions
> in places where any other value goes (eg, a field in a cstruct).
>
>
>> 3. If 2, how do I go about submitting the appropriate patch?
>
> Well, a `define-cunion' could be packaged up as a library, since it's
> just the macro definition.  But perhaps you have more changes that are
> required to make it work?  Did you change more than just "foreign.ss"?
>
> -- 
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli  
> Barzilay:
>                   http://www.barzilay.org/                 Maze is  
> Life!