Re: Macros and side-effects

[Maurí­cio CA <mauricio antunes gmail com>]

> 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.

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.

Thanks,
Maurício