[mercury-users] Abstraction barrier

Michael Day mikeday at yeslogic.com
Tue May 13 15:18:52 AEST 2003

I wish to call a predicate that returns a value and pass in some data for
that predicate to access. However, I do not wish the predicate to return
any of the data that I passed in, as it will unexpectedly go out of scope
leaving dangling pointers to randomness.

:- pred foo(magic_data, T, T).
:- mode foo(in, in, out) is det.

In the example above, the return T must not contain any references to
magic_data, or bad things will happen later. But how to enforce that?

:- pred foo(magic_data, magic_token, magic_token, T, T).
:- mode foo(in, di, uo, in, out) is det.

Perhaps this way, and only provide accessor functions for magic_data that
require a magic_token to operate, such that even if the function returns
magic_data nothing can be done with it later?

For those who care, the trickiest part of using the Win32 API from Mercury
is managing the expectations of when pointers go out of scope. It's very
easy to keep references to strings and other data provided by the
operating system that go out of scope unexpectedly, leading to trouble.


YesLogic Prince prints XML!

mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe

More information about the users mailing list