Module Initialisation? (was Re: [Haskell] (no subject))

[Adrian Hey]

On Sunday 17 Oct 2004 4:45 am, Wolfgang Thaller wrote:
> Adrian Hey wrote:
> > I'm puzzled about this idea of "module init action" in a declarative
> > language. Perhaps, if it's desirable to have some module initialisation
> > applied to a module if anything from it is used, the way to do this
> > would
> > be to have a reserved identifier specially for the purpose, like
> > "main", but at the module level. (Though this idea still seems a
> > bit strange to me).
>
> I don't see what's so strange about that.

What's strange about it IMHO is that at the moment the mere presence of
some definition in a module has no effect on actual programs. What counts
is whether or not defined thing is actually connected to the top
level main via some chain of explicit (I.E. named) dependency. This
is a property I would like to preserve. If I've understood the proposal
correctly, we'd lose this.

> At least, it's not any
> stranger than on-demand execution of IO actions in a pure functional
> language. And the toplevel "<-" is definitely a natural syntax for
> that.

True, but maybe this isn't neccessary, and even if it is, performing the
IO creation acts only if the created thing is actually used by a
program still seems the lesser of two evils to me. Of course "used"
could mean one of at least two different things..
 1- The compiler does some kind of dependency analysis and mops up
    all referenced "things which must be created" into some kind of
    pre-main action.
 2- Things which must be created are just compiled into some kind of
    thunk which gets reduced (post-main), if and when it is actually
    required by a running program.

Option 1 seems like quite a difficult thing to implement, but does
have the advantage that well defined semantics could be given to
arbitrary IO operations. It also has the disadvantage that a some
of these may be redundant (just because something is referenced
doesn't imply that is will actually be used in any given program
run).

Option 2 seems easier to implement and is nice and lazy, but
suffers from semantic ambiguity if arbitrary IO operations
are allowed (encouraged). But do we need to do this? I'm
begining think maybe we don't. The only reason it seems like
we do is because currently the only way of creating IORefs
and wotnot is via the IO monad, but this need not be so IMO.

> You're taking away a feature I want to use.

Sorry, I didn't mean to deprive you of something you would find useful.
But maybe it should be considered as a separate issue. It's not clear to
me how the compiler (or Joe programmer for that matter) would determine
and/or control which modules initialisation actions would be executed or
not, if there's no obvious "connection" to the top level main.

> 1) Initialising global IORefs is a good thing, no matter when it's
> actually done.

Yes, the hypothetical SafeIO monad allows you to do this (what you can't
do is read or write IORefs).

> 2) Being able to initialize things at program startup is a good thing,
> even if they're not explicitly referred to.

Well here is where we disagree I think. Not that I think this is a bad
thing as such, but the rules that determine which modules init actions
do or don't get invoked seem quite unclear to me if there's no requirement
that they are referenced from "main", directly or indirectly.

But maybe you could clarify what you have in mind?

Regards
--
Adrian Hey