better permute/unpermute

[Mikael Pettersson <eru!luth!sunic!liuida!mikpe@bloom-beacon.mit.edu>]

I see that in the R3.99RS (draft of Aug. 31) the sematics for function
application still uses the old definition of |permute| and |unpermute|
as global functions with constant behaviour for any number N of arguments.
I think I may have a simple solution that more accurately models the
intended meaning of allowing the evaluation order to vary not only
based on the _number_ of arguments, but also on the argument expressions
themselves, the environment and the receiving expression continuation.

Let us define a function |order| as follows:

	order : U -> K -> Exp* -> (Exp* -> Exp*)x(E* -> E*)
	axiom : if <p,u>=order rho kappa E*,
		then p is a permutation,
		     u is a permutation,
		     and p and u are each others inverses.         (*)

(*) I'm a bit uneasy with this wording since there's a type conflict
    there. However, the same conflict is in the R3.99RS soo...

The idea is to allow |order| to rearrange the arguments freely based on
all the information a compiler might want to use. Non-determinism at
run-time is ruled out however.

The equation for application can then be modified to read:

	E[(E0 E*)] = lambda rho kappa .
			(lambda<permute,unpermute>.
				;; same body as before
			)(order rho kappa <E0>&E*)

Is this an appropriate definition or have I missed something?

/Mike
-- 
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ...!{mcsun,munnari,uunet,unido,...}!sunic!liuida!mpe