Default Marshallers / Arbitrary expressions as marshallers

Hi again, I noted Gour filed a ticket for 'allowing arbitrary expressions as marshallers'.
This sounds interesting, but I wonder which would be the most sensible implementation strategy. Do you suggest to implement hs98 expressions using the existing framework ? Is there some existing code that could be reused ? Apart from that, I think the following additional default marshallers would make sense: a) If the hs type is defined in an {# enum ... #} hook and the C type is integral, use (fromEnum/toEnum . cIntConv) as default. b) If the hs type and C type match, and are of the form (Ptr a), use 'id' as default. This is really useful when working with opaque pointers, but maybe there are type-safety related reasons why this shouldn't be done. c) Additionally, we could allow the user to add other default marshallers, depending on the combination of hs/C type. If I recall correctly, Duncan had some ideas for this one ? best regards, benedikt

"Benedikt" == Benedikt Huber
writes:
Hi Benedikt! Benedikt> This sounds interesting, but I wonder which would be the most Benedikt> sensible implementation strategy. Do you suggest to implement Benedikt> hs98 expressions using the existing framework ? Is there some Benedikt> existing code that could be reused ? I'm glad you're interested for this ticket. Have you tried to implement something? Benedikt> a) If the hs type is defined in an {# enum ... #} hook and the Benedikt> C type is integral, use (fromEnum/toEnum . cIntConv) as Benedikt> default. It sounds good to me. Benedikt> b) If the hs type and C type match, and are of the form (Ptr Benedikt> a), use id' as default. This is really useful when working Benedikt> with opaque pointers, but maybe there are type-safety related Benedikt> reasons why this shouldn't be done. Cannot comment on this one. Benedikt> c) Additionally, we could allow the user to add other default Benedikt> marshallers, depending on the combination of hs/C type. If I Benedikt> recall correctly, Duncan had some ideas for this one ? It seems I missed those... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

I apologize for extra 'noise' by not realizing that Benedikt posted reply on the tracker explaining the workaround with working example. Thanks a lot! Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

I apologize for extra 'noise' by not realizing that Benedikt posted reply on the tracker explaining the workaround with working example. Hi Gour, sorry for the late reply. To clarify, I ported c2hs to use language.c (my summer of code
On 30.10.2008, at 22:38, Gour wrote: project), which fixes a few bugs in the C frontend. Additionally, I fixed a few additional bugs in c2hs, and, as a little bonus, implemented enum define hooks. Enum define hooks aren't essential though, you can easily simulate them using inline C. I've chatted with duncan a while ago, and he told me that manuel or he will take a look at the patches when there's time, but they're quite busy now I suppose (with the upcoming release of ghc 6.10). Anyway, I'm still available for questions or help. best regards, benedikt p.s.: It would be nice if the tracker would support CC emails, to stay in touch with updates on tickets
Thanks a lot!
Sincerely, Gour
--
Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- _______________________________________________ C2hs mailing list C2hs@haskell.org http://www.haskell.org/mailman/listinfo/c2hs

"Benedikt" == Benedikt Huber
writes:
Benedikt> Hi Gour, sorry for the late reply. No problem. Benedikt> To clarify, I ported c2hs to use language.c (my summer of code Benedikt> project), which fixes a few bugs in the C Benedikt> frontend. Additionally, I fixed a few additional bugs in c2hs, Benedikt> and, as a little bonus, implemented enum define hooks. Enum Benedikt> define hooks aren't essential though, you can easily simulate Benedikt> them using inline C. Still, 'enum define' hooks are nice add-on and it enhances c2hs functionality. /me would like to see c2hs as ffi-tool-of-choice for Haskell users. Atm, however, most of pkgs use hsc2hs...it looks having some more examples/docs of using c2hs would be great - like having example from the Real World Haskell book (FFI chapter) done in c2hs or something... Benedikt> I've chatted with duncan a while ago, and he told me that Benedikt> manuel or he will take a look at the patches when there's Benedikt> time, but they're quite busy now I suppose (with the upcoming Benedikt> release of ghc 6.10). Right. He told me it's on todo list, but in the meantime I'll use your branch. Benedikt> Anyway, I'm still available for questions or help. Private email or sending here? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

Still, 'enum define' hooks are nice add-on and it enhances c2hs functionality. Yes, they're certainly easier to manage from the library author's
/me would like to see c2hs as ffi-tool-of-choice for Haskell users.
Atm, however, most of pkgs use hsc2hs...it looks having some more examples/docs of using c2hs would be great - like having example from the Real World Haskell book (FFI chapter) done in c2hs or something... At least there's gtk2hs, but they use a private fork of c2hs - I think
On 06.11.2008, at 14:35, Gour wrote: point of view. Improving automatic type mapping seems to be a good idea as well. there were plans to merge them at some point though.
Benedikt> I've chatted with duncan a while ago, and he told me that Benedikt> manuel or he will take a look at the patches when there's Benedikt> time, but they're quite busy now I suppose (with the upcoming Benedikt> release of ghc 6.10).
Right. He told me it's on todo list, but in the meantime I'll use your branch.
Benedikt> Anyway, I'm still available for questions or help.
Private email or sending here? It's probably best to send general suggestions and comments to the list. If you have some questions/bug fixes specific to the port, I'm fine with private email, too.
best regards, benedikt
participants (2)
-
Benedikt Huber
-
Gour