Maybe impure functions aren't such a good idea...

[Fergus Henderson]

Peter Schachte, you wrote:
> In trying to do purity checking of function applications, I've realized a
> couple of problems:
> 
>   1.	functions aren't identified until mode checking, so I'd have to move
> 	the code for handling this from modecheck_unify.m to purity.m.

I don't consider that to be a serious problem --- conceptually
speaking, the code for identifying function calls should be
part of the "post-typecheck" pass.

>   2.	More importantly, impure functions aren't likely to be very useful,
> 	or at least not very flexible.  Since they can't be reordered from
> 	where they're placed when they're put in superhomogenous form, they
> 	can't be used in backwards modes.  And although we'll give them a
> 	left-to-right ordering, that still seems less obvious and clear to
> 	me than the ordering of one goal after another.

This is more of a problem.  In particular, currently the conversion to SHF
in make_hlds.m does the wrong thing for nested function calls:
for example,

	p(f(g(X)))

becomes
	
	F = f(G),
	G = g(X),
	p(F)

rather than

	G = g(X),
	F = f(G),
	p(F)

This is currently necessary to avoid performance problems in type checking,
but it causes problems for mode inference of functions and it would cause
problems for impure functions.

> At the moment, I'm leaning toward just pulling the plug on impure functions,
> at least for now.  What do you think?

For now, that is probably the right decision.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.