On Sun, Oct 25, 2009 at 07:05:17PM -0200, Maurício CA wrote: > > 2) Is this side effect relevant for Haskell? The C function > > (...) definitely has a side effect. But no language wrapping > > this function should need to care about it. (...) > > > So only side-effects that are side-effects for the abstract > > language are considered. All calls to g_gtype_get_type() and > > gtk_foo_get_type() return the same constant. So does it matter > > for the abstract language how this constant is implemented? > > I usually consider all foreign code to have possible effects. I > see no beneficts in doing otherwise, although I don't speak for > other haskellers. If I dress something into a Haskell "pure" > value, I have no guarantees on when it is going to be first > determinated -- for instance, I can't be sure g_type_init has been > called before gtk_foo_get_type() -- and I get little in exchange. If global initialization is not possible, then the wrapper for every such function/value must check if the initialization has been already done and possibly perform it. This way they still behave like constants. > Just to show you how I got into trouble: using the usual tools > for binding from Haskell, I have to choose between taking values > at compile time or runtime. Since I can't assume all values are > available at compile time, I need to have a function that returns > it at runtime. So, as an example, I would write a helper function. > > int helper_G_TYPE_DOUBLE () > { > return G_TYPE_DOUBLE; > } > > This is not usually a problem, as I have a few macros to do that > for me. But I didn't do that with G_TYPE_GTYPE because it was > among many constants, and I toke the lazy path. Well, you will have to do this for every GTK_FOO_TYPE, so it should not make much difference... Anyway, such wrapper needs to ensure g_type_init() is called before evaluating GTK_FOO_TYPE. Yeti _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list