Re: Macros and side-effects

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

On Sun, Oct 25, 2009 at 11:29:59AM -0200, Maurí­cio CA wrote:
> I just had this small anoyance: when writing bindings from Gtk
> to another language (Haskell, but it's not Gtk2hs, it's just
> a personal use binding), I assigned constants to the value of
> many macros in GObject Type Information section. Those would be
> G_TYPE_CHAR, G_TYPE_INT etc.
>
> Those macros are actually constants, except for one: G_TYPE_GTYPE.
> It calls a function, and since the assignment was done at compile
> time, I didn't have g_type_init() called.
>
> I don't know if this is important for other languages, as
> side-effects need special care in Haskell. But is there some
> general rule I could follow on that?

Two comments:

1) This is not a small annoyance concerning G_TYPE_GTYPE.  Every single
type macro in in Gtk+ and other libs expands to a gtk_foo_get_type() 
call, just the atomic types in GObject are constants.

2) Is this side effect relevant for Haskell?  The C function

double get_log5(void)
{
    static double log5 = 0.0;
    if (log5 == 0.0)
        log5 = log(5.0);
    return log5;
}   

definitely has a side effect.  But no language wrapping this function
should need to care about it.  Conversely, every function has some
side-effects: on CPU caches and branch prediction, it can cause page
faults that the OS has to handle taking almost arbitrary actions, it
causes the internal state of the interpreter/virtual machine to change,
it takes time and consumes power.  Each such side effect is observable
-- and important for some people.  But then nothing could be functional. 

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?

Yeti