Partial Instantiated structures (free -> free)

Lee Naish lee at cs.mu.oz.au
Mon Oct 20 17:48:14 AEST 1997


A couple of thoughts about this issue.

One "traditional" way of expressing the fact that certain things are
"untouched" is to uses polymorphism at the type level.  By defining
employee as follows

:- type employee(N,A,P)
	--->	emp(
			N,		% name
			A,		% age
			P		% department
 		).

we could use the type employee(string,int,string) for code which might use
all components and the type employee(X,Y,string) for code which only uses
the department.  I'm not sure if this technique would work (in this case) in
Mercury.

In the declarative view of modes, mode checking is equivalent to checking the
success set is a subset of the "mode set", thus making use of failure information
makes sense for mode checking.  Using this information, in general, allows more
precise mode checking.  However, it is reasonable for a language such as Mercury
to impose additional constraints on modes (as well as being well moded from a
declarative view, there will be additional restrictions) or not use all possible
information to prove well modedness.  I think the "error" example is a strong
argument in favour of using failure information in the mode checking algorithm.
Only using failure information from certain predicates (eg error) would solve
some of Mark's objections to the current algorithm but I think such things
tend to be frustrating in the longer term (you define things which are equivalent
to certain builtins but can't convice the compiler to accept them, etc).  One
approach is to explain well-modedness in two steps: programs are well moded if
<some relatively simple condition> holds; they are also well moded if <some
more complex condition involving failure holds>.  It may be that the first case
is sufficient nearly all the time.

	lee



More information about the developers mailing list