Re: Macros and side-effects

[David Nečas <yeti physics muni cz>]

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