From: Axel S. <A....@ke...> - 2005-08-23 16:10:31
|
Sorry, my last email took a bit longer to write, so I missed your reply. On Wed, 2005-08-24 at 00:18 +1000, Manuel M T Chakravarty wrote: > > > I understand why you like this, but what I am concerned about is that > > > you now start to replicate the functionality of fun hooks (which I guess > > > were added after you had already done all the design for Gtk2Hs). > > > > I think they were indeed added after I forked c2hs off. I've just looked > > at the documentation of the fun hook. I admit that having a maybe(..) > > option is like marshaling magic that looks like it should be in the fun > > hook. However a nullPtr can only be passed by c2hs; we always need to > > pass a newtype-wrapped nullForeignPtr to the function. Hence it seems > > that the nullPtr issue arises as soon as you allow clever things in the > > {#pointer #} hooks. > > > > Similarly, the issue of sometimes passing a PangoFont as (Ptr PangoFont) > > instead of the newtype-wrapped ForeignPtr seems to be the result of a > > more expressive {#pointer #} hook. We need exceptional cases e.g. when > > we bind a function to free a PangoFont (in pre ghc-6.00) which naturally > > takes a bare pointer. > > Yes, but the idea of the call hooks was really that they just automate > the call and none of the argument and result marshalling. In contrast, > fun hooks do argument and result marshalling (and internally use call > hooks to do the actual FFI call). I see your point of view. However, I really, really don't want to keep the call-hooks as they are: a) I don't think that wrapping and unwrapping of newtype and ForeignPtrs is marshaling in the sense that data is changed/copied. Hence from the design point of view, it is inconsistent that call hooks don't take their pointer arguments as the user has declared them. For consistency, call hooks should already wrap and unwrap pointers (but only pointers). The extension with maybe(..) and potentially bare(..) might be necessary, which I admit is a pain. b) I absolutely dread the thought of changing all of gtk2hs. No matter how good an automatic code generator and merging tools are, it is going to be much more work than 2-3 hours to incorporate your call-hook style to Gtk2Hs. I'm sorry that I'm kind of saying, "my way or the high way", but it would be a lot of work for rather little benefit. I think any solution that is acceptable to me (it seems I have to exclude Duncan here) will have to make do with changing your c2hs function hooks to Gtk2hs' c2hs semantics at least for *the arguments*. > I fully understand that when you made your design, c2hs didn't support > all this, so you had to find a different solution, but it seems a bit > awkward to add some fun hook functionality to call hooks in the current > c2hs. > > I don't know what your code generators exactly automate, but would it be > feasible to generate fun hooks? (I'd be happy to add more intelligence > to the default fun hook marshalling if you need that.) The code generator spits out a complete module for a widget. You then have to modify all functions that take arrays, or return GSList or does anything besides setting and getting a value. If we change things on large scale it would mean that we replace the trivial function with the stuff the code generator produces and hand edit all non-trivial functions. > > If I got this right, then I see how code can be broken. But I think the > > abstraction that c2hs gives is not quite right in both cases. In your > > version, you let the user declare special treatment for PangoFont but > > don't actually honor it. In our case we don't honour return values since > > they are always (Ptr PangoFont), just like your arguments (and return > > values). > > The idea behind call hooks is to not do anything about marshalling. > It's just the plain function that's automated. All c2hs does is provide > the necessary marshalling functionality (in form of the with function), > but it's up to the user to do the actual argument marshalling. I think > that's a consistent view. I guess it is consistent to provide the bare minimum and a fully automated way. I still think it is slightly inconsistent that the user declares a pointer P but then only gets Ptr P in all the call arguments and returns. Maybe we can have something in between: A call hook that marshals pointers as described in "The Right Thing" table, but otherwise behaves like {#call#}. > > One could fix the pointer hook by specifying the finalizer and let c2hs > > automatically create the corresponding code. I don't really like that, > > though, since sometimes things are too complicated to be left to c2hs. > > I agree. I think the "Right Thing" is doable. (I think it's time to rename that approach). > > > BTW, I just had a look at c2hs' source and unfortunately our two source > > > trees have diverged here. I guess when I added fun hooks, I changed the > > > type of PointerMap already, so a patch from your tree wouldn't apply > > > cleanly. > > > > Can you recover what has changed? Your darcs repository does not reveal > > any information on c2hs/chs/CHS.hs. > > Did you get the repository with --partial? > > darcs changes c2hs/chs/CHS.hs > Oh, no, I just looked at the web interface. Axel. |