functor and arg break encapsulation

[Tyson Richard DOWD]

Some time ago, before this list was around, fjh sent this:

> Hi All,
> 
> A down-side to functor/3 and arg/3 is that they break encapsulation:
> they can be used to traverse even abstract data types.
> 
> I don't think there's much we can do about that; often when using those
> sorts of predicates, you really do want to break encapsulation.
> (Consider, for example, implementing RPC or databases by converting
> data into flat binary streams and sending it down a wire or saving it
> on disk.)
> 
> One thing we might consider, however, is providing both "safe"
> and "unsafe" versions, with "unsafe" versions behaving as they do now,
> and with the "safe" versions failing if called for an ADT from
> a module other than the module that defined the ADT.

The implementation of this is somewhat tricky, and raises a few issues.

foo.m defines type foo as an abstract type. 
bar.m imports type foo. 
	- If I get a foo, then call functor on it from bar, it fails.
	- If I get a foo, then call functor on it from foo, it succeeds.
	- If I get a foo, then create a closure of the call to functor,
	  pass this back to a predicate in foo.m, which calls it, what 
	  happens?
	- If I get a foo, then create a closure of the call to functor,
	  curry the first argument in bar.m, pass this back to a 
	  predicate in foo.m, which calls it, what happens?
	- If I get a closure from foo.m, which happens to be a call
	  to functor of something of type foo, and them call it in
	  bar.m what happens?
	- Any other variations of above.

There is another issue this problem raises - dead procedure elimination
assumes that if the definition of a type is local, then we can eliminate
the Unify, Index and Compare predicates for that type if no type_info is
used. This now gets more complex - if any type in the module that is
exported is built up out of local types, those types can be extracted
from the exported type using arg/3. So the definition of liveness for
procedures has to be extended to include references from the
pseudo_type_infos for exported types (for baffled readers, a
pseudo_type_info is just like a type info, but might contain variables
in its type arguments, they get generated as part of the
base_type_layouts, describing the types of arguments of constructors).
I'll be fixing this problem soon.

Also, in a related topic, Peter Schachte expressed some interest in it
also being desirable for types to be able to deny access to such
predicates (on a type-by-type basis, regardless of whether it is "safe"
or not), for commercial secrecy reasons. For the "safe" versions, they
can fail - no problem, but the "unsafe" versions may return
"<<invisible>>" or something.  However, this can be implemented by hand
using the C interface at the moment, so it's not too important at the
moment. (Besides which, it was generally agreed that you'd probably get
more protection from a strong license agreement).

-- 
       Tyson Dowd           #          Another great idea from the 
                            #            people who brought you
      trd at .cs.mu.oz.au      #               Beer Milkshakes!
http://www.cs.mu.oz.au/~trd #	         Confidence --- Red Dwarf