[m-dev.] for review: document dl__close caveats

[Tyson Dowd]

On 31-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 31-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > 
> > You might want to add that only implementors will know all this stuff.
> 
> I tried to document it in a way that would make it possible for
> ordinary programmers to use, based on a high-level operational
> semantics, without depending on low-level implementation details.
> Ordinary programmers should be able to reason about which procedures,
> terms, types, and instances their program will use.
> These are all language-level constructs, not implementation-level
> notions.  Although the documentation does mention static data,
> it goes on to explain which language-level constructs could involve
> references to static data.
> 
> If you think I failed, please let me know ;-)

I think using the term "references" is fundamentally misleading, because
a good Mercury users won't know (or need to know) what a reference is.
It's not clear to users when they can be sure about using a reference
and not using a reference.

Hence, I think it would be good to make this explicit by recommending not to
call dl_close unless you understand the implementation.  The word unsafe
should be used (possibly it should be called unsafe_dl_close).

> I didn't spell out the correspondence between "procedures" and "code",
> because I thought that was obvious.  But I can do that if you think it
> is worthwhile.

This isn't so bad.  But the reference thing seems to me to indicate that
you have to know how Mercury is implemented.

> > Also mention that if you copy/2 the arguments you should be able to
> > avoid these problems (but this is untested).
> 
> I thought about mentioning copy/2.  But copy/2 doesn't copy
> type_ctor_infos and base_typeclass_infos.  So it won't work in the
> general case.  I didn't think it worthwhile to document the cases
> that it would work for, because this is starting to get a bit too
> implementation-specific.
> 
> On the other hand, the fact that copy/2 won't work is perhaps a good
> reason to document it.  What do you think?

Perhaps we should go for a different approach to dynamic code loading.

(discussion with fjh offline ....)

Fergus and I just discussed this and it seems the "right" approach is to
compile dynamically loadable code differently.  This would allow us to
solve 2 problems:

(1) the MLDS wrappers for closures could be generated for the
dynamically loaded code, so the bugs with the MLDS backend and dl code
would be solved.

(2a) previously static ground terms would be allocated on the heap
(just once, using an initializer) so there is no need to copy these terms
before you dl_close.

(2b) we could dynamically allocate the RTTI (just once, using an
initializer) so there is no need to copy type_ctor_infos and
base_typeclass_infos before you dl_close.


-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------