[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: scheme@MC.lcs.mit.edu*Subject*: better permute/unpermute*From*: Mikael Pettersson <eru!luth!sunic!liuida!mikpe@bloom-beacon.mit.edu>*Date*: Sat ,11 Nov 89 00:15:55 EDT*Organization*: CIS Dept, Univ of Linkoping, Sweden*Sender*: scheme-request@MC.lcs.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

- Prev by Date:
**Re: Scheme to Commonlisp** - Next by Date:
**A-STAR in Scheme** - Previous by thread:
**why eval is evil** - Next by thread:
**A-STAR in Scheme** - Index(es):